Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - dannotestein

Pages: 1 2 3 4 5 6 [7] 8 9 10 11 12 13 14 ... 51
General Discussion / Re: How do the OPEN.X assets work?
« on: June 20, 2016, 01:53:45 am »
Danno, at same time I agree n disagree with you.

I agree,
4) make more coins born in graphene bitshares blockchain, it is pretty great we have peerplays, muse here.....if we could patner with more projects to born here with support that is pretty good way to grow this is pretty much make a decentrilised ecosystem grow from bottom to top, a plataform for projetcs n a exchange for them, decentrilised, top tech. Is there a lot projetcs borning everiday in crypto space, huge market.

I Disagree
2) In my opinion our partnership with openledger is a bless, they are promoting our tech, our bts, they are making it happen for them n for is the way the world works right dont cut it because so you are out of game.....we have to join togheter n grow togheter try to bring transparency for open.assets....good volume for them, better for us, better for our tech, I know bad things can happen but we have to educate people about it

Sidechains I do not understand fully but it only makes sense if it can improve our game, but in a decentrilised way, if we are talking about multisig we could partner with supernet to bring a new player, a new option to people, but Im not sure that is the point but I would be glad to hear more about this.
I'm not sure what you're disagreeing with me on 2) about, as I read your message as supporting OPEN. asset coins as a viable trading methodology. I'm a big supporter of 2) for now (on a very technical level, too, as BlockTrades implements and supports the OpenLedger gateways for Ronny). I actually think it's the best solution we can afford now for many coins. But I think we should try 1) for coins we don't have time to support with a full gateway.

Just to clarify what I'm calling a sidechain, it's a truly "trustless" method of sending coins in and out between two different blockchains without requiring any custodian(s). But implementing this isn't a small undertaking, and in the current state of crypto, it would have to be done on a coin-by-coin basis.

General Discussion / Re: How do the OPEN.X assets work?
« on: June 20, 2016, 01:09:45 am »
I know of at least four ways we can create tradeable assets on BitShares, and I think all have their place in the future (some now):

1) Smartcoins that allow speculative trading based on feeds with no gateways in or out. These can be used for coins where gateways are difficult to implement for technical or regulatory reasons (everyone knows the regulatory challenges associated with fiat gateways, for example). If witnesses are willing to provide feeds and we have an active committee willing to approve them, we could rapidly enable smartcoin trading for any number of crypto assets. Of course, we may still be faced with the same issue finding people willing to short smartcoins into existence as we have with fiat smartcoins, but I think we might find quite a few people willing to short very speculative crypto coins. I've certainly seen a few I would short.

2) 3rd party-backed UIAs like the OPEN. assets. To support real trading, these need to have gateways associated with them, so there is additional work required to support them. They also bear the risk of the backer being robbed or even an insider embezzling the funds, so it's important we vet them before promoting them.

3) For coins with larger deposit amounts, a multi-sig backed coin can potentially offer additional security versus 2. This is technically feasible, but there's a lot more overhead in supporting these coins, so I think it's only appropriate for assets that represent substantial amounts of money. And doing the first such coin will require a lot of work to create the mechanics for it.

4) The "holy grail" is a true sidechain coin, that allows coins to move from one blockchain to another. This requires a huge amount of work, and in some cases, political agreement between the chains involved. At the current time, I only see this as being appropriate for very top tier coins in terms of trading potential (e.g. Bitcoin, Ethereum, and graphene-based blockchains at the moment).

We're doing 2) today. I think we should experiment with choosing some "hot" coins with non-standard wallet technology that makes gateway implementation a pain for 1). And once I've got some time, I would like to put development effort into 4) for btc and/or ethereum, depending on the state of things when we get there. I'd actually prefer going after 4) before 3), since I think the cost/benefit ratio favors 4).

General Discussion / Re: Bitshares Bank UI
« on: June 19, 2016, 07:39:31 pm »

I think you are mistaking what is being suggested here.  At least in my mind, the idea is to have a simplified interface for users to easily exchange one asset for another.  It should be something like what Coinbase offers in their standard interface e.g. you choose how many BTC you want to buy and it tells you how much it will cost in dollars, and you click ok to complete the order. 

Obviously in the Bitshares wallet it would be more complex than that because it should be possible to trade any supported asset for any other supported asset, provided there is enough liquidity.  This would require a Blocktrades- or Shapeshift-like interface, but I don't see why there would be a need for multi-hop, atomic transactions. 

What are you going to do if there is no direct liquid market between two assets, but there is liquidity between each of them and some third asset?

In fact, this actually happens now on DEX. Not much  trade other than assetX:BTS.
BlockTrades pricing algorithms already use this kind of information to compute pricing between assets that don't have direct liquid markets between them.

General Discussion / Re: Bitshares Bank UI
« on: June 19, 2016, 06:53:45 pm »
Actually, we already do have a Shapeshift-like "bridge" feature offered by Blocktrades, but I believe it's dedicated to exchanging external assets for internal ones.  I think all we need, then, is a separate interface that does the same thing for exchanging between internal assets.  @svk, @dannotestein - is there any reason this can't be accomplished fairly easily?
Yes, we can easily offer this functionality. We could even offer both thru the same interface instead of two separate interfaces if it's more desirable.

General Discussion / Re: Bitshares Bank UI
« on: June 19, 2016, 04:14:34 am »
For average Joe, bitshares is missing something like ripple path finding. It makes automatic currency conversions smart way. For example, suppose you save in bitGold and you want to make a payment to online shop which accepts bitUSD, but is no market between bitGold and bitUSD. The system goes and checks different order books, and finds a cheapest path for you like BitGold -> BTS -> BitBTC -> bitUSD. This is a killer feature of ripple and must have in bitshares in order to be accepted by merchants and by general public. It is not trivial to implement though.

I am afraid that this is a little bit more complex than UI tweaking.

What if we could have different skins or themes for regular and advanced users? The Ripple wallet was already very clear and had both.

I am currently looking for a graphic designer who would like to create some mockups for the BitShares Exchange.

It should have:

a) a simple interface for regular users, clear buttons, clear buy/sell/deposit/withdraw/ overview over assets
b) an advanced interface for traders, charts, order books, charting tools
c) a management interface for UIA creators etc.

Please donĀ“t forget Voting needs to be integrated into all interfaces. It is an essential feature for our platform.

Please reach out to a designer who could help us. I would pay a bounty for a good lead.

I am afraid that this is a little bit more complex than tweaking UI. A multi hop transaction  has to be atomic, otherwise results can be unpredictable.

As for UIA, they are crippled in bitshares. If done right, the same loan principle should be applied, as with MPA, but based on trust instead of collateral. This would allow to create LETS societies in bitshares, which would be amazingly cool.
Could you say a little more about LETs societies? I tried to search via google, but nothing appropriate popped up for me.

General Discussion / Re: How do the OPEN.X assets work?
« on: June 19, 2016, 04:00:56 am »
cool, even with OPEN.STEEM? coinmarketcap doesn't show STEEM trading on CCEDK
OPEN.STEEM is listed here on CMC, although not all associated markets are shown:
OPEN.STEEM are the 3 OpenLedger listings.
But better data is available here:

General Discussion / Re: makerdao cloned bitshares graphene?
« on: June 17, 2016, 05:08:39 pm »
Xeroc if you access you will see that there is only eth:makerdao is not listed......
If orderbooks are shared that pretty good.....if we could dvelop togheter better yet.......
The markerdao guys just made a decision to show only their own assets in their version of the web wallet, IIRC.

There's actually been a lot of people who have suggested the same for OpenLedger UI, although I'm not personally in favor of the idea. Personally I think it makes sense for an exchange to "highlight" the markets it is associated with or would like to promote (for example a pair between two exchange such as OL to Transwiser, for instance), but still leave other markets viewable (except to block out any well-known scammy UIAs like the "lisk" one that doesn't honor it's backing).

There's been a lot of concern expressed about liquidity associated with having a lot of pairs, but with bots like ar3b1tr around, you can place orders on markets with no orders and get fills, which I think is actually pretty cool.

Technical Support / Re: Wallet shows invalid state after sometime
« on: June 17, 2016, 03:22:13 pm »
Perhaps there were networking issues between your cli and a remote node?
Dan may be running local nodes, so didn't see such issue.
My steem witness is on a local node and I was assuming xeroc did as well :-)

Technical Support / Re: Wallet shows invalid state after sometime
« on: June 16, 2016, 03:13:51 pm »
not re-producable here unfortunatelly .. but it happens quite often on my steem cli-wallet ..
the usualy behavior is something like this

> unlock xxxxx
> list_my_accounts
> transfer x y "z STEEM" "" true
> transfer_to_vesting ..

If I keep the cli-wallet open for a few minutes doing nothing with it .. then the call after it will return the error message above
I use my steem cli-wallet in very similar ways reasonably often, but I haven't ever seen this error (although I suppose it's possible that console spam has scrolled it off the screen). I'm starting to wonder if it's not some difference in how our wallets or witnesses are compiled.

Technical Support / Re: Wallet shows invalid state after sometime
« on: June 16, 2016, 02:34:32 pm »
I noticed that error also from time to time ... no clue how to fix this ..
@dannotestein, do you have an explanation for this?
It looks like that error means the wallet is sending data at an inappropriate time for the server to process it. Do either of you have a test case that can reliably reproduce the error so that we can investigate it? Also, are you both using python libraries to communicate with the wallet?
That error happens even in the cli-wallet itself .. not python interaction at all .. (at least this happend to me with the steem cli-wallet .. not using the bts cli-wallet much)
ok, we're not experiencing this here, and we use the cli-wallet pretty heavily, of course, so it must be something different about the usage (or the way it's being compiled). Are you guys using pre-built binaries? Also, do you either of you have a somewhat repeatable test case?

Technical Support / Re: Wallet shows invalid state after sometime
« on: June 16, 2016, 02:06:29 pm »
I noticed that error also from time to time ... no clue how to fix this ..
@dannotestein, do you have an explanation for this?
It looks like that error means the wallet is sending data at an inappropriate time for the server to process it. Do either of you have a test case that can reliably reproduce the error so that we can investigate it? Also, are you both using python libraries to communicate with the wallet?

I'd like to see the discussion separate the affordability/priority issues from the underlying best approach.

If Ken has a whale sponsor with deep, um, blubber, what is the best thing to build for the ecosystem?
Please read my post above, my concern is not just affordability. Assuming one approach is the "best" is itself an error, IMO.

BM after he decided that the current GUI implementation of stealth was too problematic, I came to the conclusion that what we really need at the moment is simply "blinded transactions" and I think this should be the immediate focus.

I think the problem was money and time. He is way too focused on Steem right now guys to work on Stealth which is why BitShares Munich team is going to finish that project. Chris and Rodrigo are bringing whales, and whales want privacy. Marketing such an important product like Stealth however will need to include all the things that the competition, media and trolls in the comments would fire at us saying "hahaha look they are releasing a half assed product!" Instead, I'm choosing to take a bit more time and do it right the first time.
First Mover Advantage. Give the world something that it so sorely desires, do it right the first time, and market the hell out of it so that when the world sees it, they shut the f*ck up and say "ok, now this is cool". Total anonymity, total untraceability, ring sig, automated backups via ipfs/ipns, super tight integration with graphene-ui and ease of use, so easy in fact that Savers and Whales actually WANT to use it. I will not settle for anything less. I can take us a long way with this even with a little bit of funding so it only makes sense to spend the funds on the proper path instead of a "just do it this way for now" approach.
It's not a matter of "just do it this way for now". There's practical usability issues that make blinded transactions the "right approach" for many transactions, so blinded transactions are not just a detour or even a "half-way" towards stealth transactions. We ultimately want to support both methods, IMO, but blinded transactions are 1) easier to use, 2) not prone to losses, and 3) easier to implement. It would be difficult for me to support a worker that favors supporting stealth before supporting blind transactions. I would like to see a lower cost worker created for blinded transactions first, then a higher cost worker created to support stealth after blinded transactions have been successfully implemented.

I would also like to hear from @kenCode about his Stealth plans. A few days ago he said that we should be expecting an announcement soon. @arhag just said that there is a good way to add privacy via another way. Have there been discussions between the two of you?

We are still working on the job description so that we know what's done, what's not, what I want to add to Stealth (ring sigs, possibly CN/CT or a combo of both), ipfs/ipns and who my confirmed network of consultants will be. I have an experienced cryptographer on my side but he's not cheap (even for Turkish labor) as well as a nice sized crew savvy enough with graphene-ui, graphene and ipfs/ipns.
@arhag I am interested in seeing every possible way we could do this. Stealth can whip monero, dash, zcash and the lot of them if we do this right. Leaving nothing for the competition to point at.
Even with Tor and I2P support (please Lord give us global meshnet soon!), you have to think about the NSA and what sort of crypto tools they might be able to employ to crack Stealth. Whales want privacy so Stealth has got to set the new standard.
Just my 2 cents: based on discussions I had with BM after he decided that the current GUI implementation of stealth was too problematic, I came to the conclusion that what we really need at the moment is simply "blinded transactions" and I think this should be the immediate focus.

I haven't had time to read this whole thread, but Eric and I worked out a way earlier today to do a fully-decentralized version of sidechains that doesn't require multi-sig authorities, which from my limited reading would overcome the major objection originally expressed about sidechains in the OP. It wasn't prompted by this post, but by interest in linking graphene-based chains to ethereum (the original impetus being to link to ethereum as part of a move to get DAO support for peerplays). There's a fair amount of work involved in the implementation, but not an insurmountable amount by any means. So if peerplays is successful in getting DAO funding, it looks like we'll make this happen.

I find that very hard to believe, because I had convinced myself this is fundamentally impossible. Very interested to see what your solution is, what its limitations are, and whether it actually addresses any of the concerns of the OP.
There's lots of details I don't have time to go into now, but the essence of the technique is to extract sufficient data from one blockchain to create a proof-of-burn (or proof-of-lock) that the other blockchain will accept if published to that blockchain. On etherium, a smart contract would serve as the arbiter for that proof. On a graphene blockchain, the validation would be built into the blockchain protocol. Most of the details lie in how to efficiently construct such proofs. Part of the proof is information that indicates the owner on the blockchain accepting the proof.
It's hard if not impossible for one chain to trust something happened on another chain. Even if every node validates every block of both chains, it still doesn't make much sense to trust a non-trustless chain.

Bitcoin has the most potentiality to be considered as trustless;
Eth is perhaps trustless, but I doubt smart contracts are (there is always an image in my head that most of if not all smart contracts aren't trustless);
Graphene based chains are definitely not trustless.

Am I missing something?

//Update: I must be drunk..
You may not be missing anything, but I thinking you are starting with too strong an initial assumption. You are correct when you say the two chains involved in a sidechain do have trust each other, although the limits of this trust can be established such that "lies told by one chain" can only have but so much effect on the other one (the affect can be limited to fraudulent transactions for the total value passed to a sidechain, for example).

But your initial assumption that "graphene-base chains are definitely not trustless" is, in my opinion, wrong. Maybe we just have a different opinion on what level of reliability is required to be "trustless". All chains are ultimately a form of consensus among the users and in the case of rapid hardforks, trustlessness can be significantly impaired by potential rogue code inserted into the blockchain software.

But with a reasonably diverse set of users and a slow rate of change, I think it's reasonable to call them trustless. Etherium's approach to trustlessness in the face of potentially rapid change (new smart contracts being rapidly introduced) is to limit the impact of a contract performing fraudulent operations to it's own domain of users, which seems pretty reasonable to me.

Pages: 1 2 3 4 5 6 [7] 8 9 10 11 12 13 14 ... 51