Reindexing the blockchain should be a one-time event   However I have considered that yep - it would be a 'consensus based' thin client - so a thin client in the traditional sense, except that it only works on matching transaction data retrieved from multiple sources.  It all depends on the direction the project takes

Thanks!
Zathras

We have 5 days before we go live, and originally we wanted 10-14 days of consensus before that. We will not have that, but we really can't wait for the last moment.
Two implementations have consensus on the current code base now, and if we make another change, we may lose that.

I was asking to drop the whole multiple payments saying that it contradicts the basic design of my code, and it hides some complexities that we didn't think of, but you guys insisted.
It was 2 full working days with a lot of testing, and a huge patch.

At the current stage, I prefer either to keep the consensus without limiting user freedom for multiple accepts and ask Zathras to join the consensus, or roll back the whole multiple payments feature.

Actually, unfortunately this is not simply a UI issue for me.  It goes to the core of the logic I currently apply.  Let's say there is an accept in block 3 for 50 MSC.  I then search block 3 to block 3+timelimit for payments to the seller.  For example:
1) Accept 50 MSC for 5 BTC in block 3
2) Check blocks 3 to 9 for payment, yep found 5 BTC payment to seller in block 8
3) Accept 50 MSC for 5 BTC in block 6
4) Check blocks 6 to 12 for payment, yep found 5 BTC payment to seller in block 8

Oops, same payment has now been applied to two accepts.  So as we can see logic was written with the design assumption of a single accept per address per sell.

Also we can't simply merge the two accepts, what happens if the seller updated the sell with a different price in between the two accepts?  They have to be handled as seperate entities and thus we have to define an order of precedent for applying payments and so on.

I'll put my thinking hat on and go review my code logic, but there will be some complexities to allowing this.

Brings up another interesting question that needs to be answered - can a buyer have multiple 'accept offers' to the same seller open at the same time?  There (iirc) is nothing in the spec that says you can, or that you can't.

I actually haven't coded for that scenario at all, I'll have a look through your test case to see how Masterchest has handled it.  At first thought I think it adds unncessesary complexity (allowing multiple accepts from the same buyer at the same time - for example we then need to explicitly define in what order/how bitcoin payments are applied to which accept) - but I haven't looked at it deeply.

J.R. - can we get a ruling?  Multiple 'accept offers' from the same buyer to the same seller open simultaneously.  Yay or nay?

FYI:
* Graz (assuming from the above) allows multiple accept offers from the same buyer, unsure how applies payments
* Bitoy allows multiple accept offers from the same buyer, and applies payment to the first accept until paid, then to the next accept until paid and so on.  But only for whole payments, so if the first payment did not fully pay the first accept, the second payment would be applied to the first accept and any remaining would be an overpayment and not applied to the next accept offer.
* Masterchest hasn't factored for multiple accept offers one way or the other - will need to evaluate behaviour

I was wondering about the payment itself. Currently it's simply a transaction with the seller + exodus referenced and no message. I'm trying to figure out, if there is an edge case where I could scam a seller by buying something else and at the same time making the payment for an dex offer? At least related to dex it should be fine, as long as there is only one offer at the same time per seller allowed.

Gotcha, thanks a lot! My very first thought was that this fee is to make sure the transaction confirms in time, but this makes a lot more sense now.

I assume the reason why Bitcoin payments are not combined and included in the accept transaction is to prevent the case that two users buy at the same time and one of them is screwed. And only after balances are locked after the accept offer transaction was confirmed, it's really safe?

This kind of dos protection could lead to very interesting mechanics and questions, e.g. "is it more profitable to sell higher and disable competitors or play fair" etc.

Here is an idea: from a seller point of view I'm in conflict with my interests, because I want to have a minimum of fee required to have an edge against competitors, but at the same time I don't want to run into the risk of being dos-frozen. What if the dos-fee is sent to the seller instead of the miners and credited/considered as form of advance payment?

This is not a new change as of yesterday. It has been in the spec since 2/10. Here is the history of that in the spec:

on 2/10, this clarification was added: "Please note that all transactions between the Purchase Offer and expiration block should be accumulated and that this value must be used to adjust the Purchase Offer accordingly."
on 2/20, it was clarified to read "Please note that the buyer is allowed to send multiple bitcoin payments between the Purchase Offer and expiration block which are accumulated and used to adjust the Purchase Offer accordingly."
The 2/10 change was a result of an email conversation which everyone was included on. (Sorry, I know there is a ton of email).

The change yesterday merely changed other language to more closely match what was already there. It was NOT a feature change.

Now, what graz is proposing here essentially means that as soon as someone sends payment, their reservation expires, and they can't send additional funds. I'm open to making this change if other people prefer it, but it has been in the spec for quite a while, and other implementations are doing what the spec currently says.

Zathras and Alvin, which way do your implementations go with this?

Let's try really hard to not draw this conversation out. Either way will work just fine.

Thanks,

-J.R.

Incidentally, I agree with Graz that last-minute spec changes are BAD, which is why I lean towards keeping it as is and treating this as a masterchain bug which just needs to be fixed. However, if Alvin and Zathras say it's trivial to match Graz's code, I'm open to that.

At least on my entry I have no write permissions, and the table looks empty - one has to scroll down a long way to see something.
I could repeat it here with my name and BTC/MSC address though.
Grazcoin

Ron, Craig, and I have been trying to get a more standardized method for collecting your work summaries and mutual feedback for the monthly $100k milestone bounties.

On 3/1, we'll start collecting your work summaries for the month of February.

YOUR WORK SUMMARIES ARE DUE WITHIN 5 DAYS (3/6/2013 0:00:00 GMT) to qualify for bounty payout. You can check out the form for submitting your work summaries here:

https://docs.google.com/forms/d/12RJqahjVjwRi2xXHKbhJurb4d7uWK21ZxD7EZIlMzuI/viewform

On 3/6, and 3/7 I will update our feedback form to include the appropriate names. YOU WILL THEN HAVE UNTIL 3/12/2014 0:00:00 GMT to complete the feedback form. This is also required to get a payout.

Based on feedback data, I should be able to start making BTC payments by 3/17, with MSC payments shortly thereafter.

You can see what the feedback form will look like here (seeded with names from last round, in the order I got work summaries from people):

https://docs.google.com/forms/d/1Q2ltuJiWAxBfoUYTbJYBA1REb3xwhFokgm9thLXm9Tw/viewform

You'll note that we have changed from direct percentage evaluations to a grading Q&A (the output of which will yield a percentage for each person).

Please take a look at this now, as we will be using these forms very soon (you can enter fake data to see the next page, but please don't actually submit any data with them yet!).

Thanks!

any good news about wallet？

Thanks J.R. - just talked with prophetx and located a bug with rpcport detection, commit w/ updated binary has just gone up.