Topic: IOTA - page 684. (Read 1473233 times)

Redesign is fine. Take your time, thanks for all your work here!

To be clear, if my above analysis is correct, I agree with using balance method instead of signing every tangle transaction associated with an account.

I get it.  An address can accumulate multiple payment receipts, but as soon as it "spends" any funds, a new recipient address will get the remaining balance.  This means there is no long ledger of +/- balances that will need to be resolved.

In such a case, point #1 and 3 which you outlined above are no longer true.  You must always send your remaining balance (even if not calculated*) back to a new address.

This could also mean that the following payment system could be used.

Alice receives 5 transactions into account X.

T1 = 100
T2 = 100
T3 = 100
T4 = 100
T5 = 100

She want's to send 250 IOTA to Bobs address (Y), so she makes a transaction that sends 250 IOTA from X to Y and all remaining balance goes to account X' (Alices new account.)

Any node that receives this transaction only needs to see at least 3 of the above transactions in Alices X account transaction chain.  If that's the case, even though the total balance on a node could be incorrect, the transaction can still be verified.  The node will only assume that X.Total-250 will be forwarded to Alices new account (X').  

Later, if Alice attempts to send the remaining 250 IOTAs from X', these nodes will only then have to look for former, missing transactions.

I like this.  This feels solid and allows for a users balance to never be fully known.  You can know at least how much they have, but you can never guarantee the total value of their wallet.

If we prohibit address reuse then balance method becomes indistinguishable from input method...

Only one of the transactions will be legit, the one with more PoW tied to it. Just like in Bitcoin.

Hard to say without modelling.

How will transactions be resolved/confirmed.  Alice sends two payments to two separate regions of the network.  Which transaction will be eliminated, assuming they are both the same, except for some nonce value?  This is likely a problem with the other approach, but at least if a sender engages with any funny business, creating multiple transactions referencing the same, earlier payment receipt transactions, the account can be flagged/black listed more readily.

Using the balance method, detecting this type of monkey business wouldn't be as fast.

Yes.

@CfB

That's what I thought.  I assume this means that if Alice sends a payment transaction to Bob's node and if Bob sees that Alice doesn't have the balance, Bob will request form his neighbor's all transactions for Alice that she's sent and received.

Correct?

I'd prefer balances, but dont think most people are qualified myself included to make that judgement call without fully understanding the security/technical impact it could have.

In case of either ... or and if you sure only 98% percent I will join rlh club - it just does not feal right for probability model via deterministic blockchain.

2 branches of the backend. One with inputs and another with accounts.

In which case this message has propagated through the network and many were expecting genesis this weekend.

Since you weren't gonna launch this weekend then I suggest u make your improvements

I also suggest we launch this badboy ASAP

You want community buzz? You will get a truckload after genesis brother

Explain.

Maybe we could go the both routes...

Perhaps there is a confusion somewhere. The genesis was ready last week, only frontend beta testing is scheduled/ETAed for this weekend, which is basically just playing with all dialog windows because actual transaction sending requires back-end to be on beta stage too.

Yeap. You must be 100% sure about security/correctness of new design to risk the whole consensus/project.

David said genesis would be this weekend, so 48hrs

Sorry to decent, but I'm going to have to go with my gut and vote no. I may have to re-read over the Tangle whitepaper and think about this a few times but my gut is quite well at spotting causes of bugs, loopholes, errors and exploits...

I love the idea of a balance based system and I've obviously seen it at work (with Nxt and Qora.)  But in regards to a Tangle, it just doesn't feel right...  I just think this can be exploited on a well orchestrated, well thought out double-spend attack.

From the point of view of humans #3 (address reuse) is a very good cause to spend few day to redesign and code system.
On the other hand the "consensus convergence" is a  single point of failur for the whole system.
So the answer I think is this: if you sure 100% that consensus convergence is not affected - go for addresses. If you do not 100% sure - stay with current input-output system.

I vote yes because everyone says yes!!!