Enable support for multiple concurrent sell offers from the same address #56
Comments
|
looking at this from another angle, and to cut down on address reuse, the like when i send btc to another address in my wallet because my address Thanks, Dominik Zynis Schedule a meeting with me: Need to catch up on what is happening at the Mastercoin Foundation? On Wed, Feb 26, 2014 at 9:08 PM, Ron Gross notifications@github.com wrote:
|
|
Yeah, the wallet can take care of this issue automatically for users if we On Wed, Feb 26, 2014 at 1:03 PM, Dominik notifications@github.com wrote:
|
|
That solution is clunky. Ron Gross On Wed, Feb 26, 2014 at 11:16 PM, dacoinminster notifications@github.comwrote:
|
|
J.R. - can you explain the reason for one sell offer per address, so Marv Schneider On Wed, Feb 26, 2014 at 4:19 PM, Ron Gross notifications@github.com wrote:
|
|
Sure. When it comes time to update or cancel an offer, you don't have to Not that we couldn't do all that, but it seemed much simpler to implement On Wed, Feb 26, 2014 at 1:32 PM, Marv Schneider notifications@github.comwrote:
|
|
Also, it's actually one sell offer per address per currency, so you can On Wed, Feb 26, 2014 at 1:35 PM, J.R. Willett jr.willett@gmail.com wrote:
|
|
Quick thought for defining the ID: We could say you can only have one active order per tuple of (Currency ID, Don't you think the protocol-level cluckiness of the update mechanism is Ron Gross On Wed, Feb 26, 2014 at 11:36 PM, dacoinminster notifications@github.comwrote:
|
|
That would work for cancel, but not for update, since updates are quite I think you'd have to give each sell offer from an address a sequential ID Every axis of complexity we add to the protocol slows us down, and I think On Wed, Feb 26, 2014 at 1:51 PM, Ron Gross notifications@github.com wrote:
|
|
It would work for updates, you basically give two instances of this tuple, We can post a poll at the forums and ask people how important this is to BTW I'm also open to the sequential id solution, although that comes with
|
|
Ah, I see. That would add a lot more bytes to the update message. A sell A poll is ok, but let's be very careful not to give the devs any impression On Wed, Feb 26, 2014 at 2:26 PM, Ron Gross notifications@github.com wrote:
|
|
I think I'm going to step back from the implementation details and let you close that... but the requirement of having multiple concurrent sell orders from the same address, in addition to things I detailed in #58, is an important one. This can be discussed for a future iteration of the protocol. |
|
I agree that we should take a close look at what might be perceived as an Marv Schneider On Wed, Mar 5, 2014 at 7:54 AM, Ron Gross notifications@github.com wrote:
|
|
@dacoinminster did you close this because it's not important? I don't think that the current DEx is so successful that we don't need to tweak it ... and I still argue that this is an important feature to have. |
|
See Topic 1 in #204. dexX7 pointed out if an address has an MSC sell offer and a TMSC sell offer, the protocol doesn't know which one to credit with the BTC from an incoming bitcoin send. The same ambiguity would apply here, so a creative solution is needed. |
|
Metadex can already have as many open orders as you want. Only dEX with bitcoin is affected by this issue. The issue Marv linked means we can probably never do this with dEX against bitcoin. I believe this issue should be closed (this change is something we can never do). |
|
Ah, I understand, thanks for elaborating. |
FYI - this is not targeted at the current March 15 DEx launch, but for a future version.
As a user, I want to create multiple buy/sell offers at various prices. I understand how the spec can be simplified by disallowing them, but I think this is over-simplifying things.
I think that this is an essential piece of creating a good volume on the exchange - if I have 1000 MSC at an address, I might want to sell 100 of them at 0.2 BTC, 100 at 0.21 BTC, 100 at 0.22 BTC etc...
The text was updated successfully, but these errors were encountered: