BTC->BTSX Proposal

[tonyk]

bump!

[emski]

My understanding is your proposal was to divide nodes into two groups:

- Delegate nodes determine whether delivery was completed by examining the BTC blockchain
- Non-delegate nodes determine whether delivery was completed by checking if delegate nodes published a signed statement saying delivery was completed

Where from , you manage to derive this nonsense?

It might have been a poor choice of words.  I was referring to when emski said:

There should be no need for anyone except delegates to download bitcoin blockchain.

So by "two groups," I meant that in emski's proposal:

- Group 1:  Delegates download the Bitcoin blockchain and run some algorithm, to determine whether the BTC were delivered.
- Group 2:  Non-delegates do not download the Bitcoin blockchain, so they must use a different algorithm to determine whether the BTC were delivered.

I think it is safer to have every node run the same algorithm and check the BTC blockchain to determine whether the BTC were delivered.  (It is more resource intensive on all nodes, too, but I believe the security of users' funds is more important.)

Does that clear things up?

As well as , how did you come with the rest of your baseless conclusions, in other thread on this forum?

I've been posting a lot lately, in many different threads.  I have no idea what discussion you are referring to.

nodes other than delegates are irrelevant. They could as well monitor btc blockchain but that doesn't matter.

[emski]

btsx becomes spendable on transaction cancel or completion + possible dispute time 1-6 hours for example or depending on currency ONLY if we care that much for 51 delegate conspiration.

The other day I had a Bitcoin transaction take ~3 hours to be confirmed.  I wasn't doing anything weird, it was a totally normal payment to a single address (plus change address) generated by the Bitcoin core client.

If that happens, what does your proposal do?

My proposal requires the Bitcoin to be provably unconfirmable (based on the Bitcoin transaction's expiration time) before the BTSX blockchain is allowed to conclude it will not show up.

I call this tweakable detail that might impact only confirmation time....

[tonyk]

I've been posting a lot lately, in many different threads.  I have no idea what discussion you are referring to.

Chose, the one you feel most combatable defending...

[theoretical]

My understanding is your proposal was to divide nodes into two groups:

- Delegate nodes determine whether delivery was completed by examining the BTC blockchain
- Non-delegate nodes determine whether delivery was completed by checking if delegate nodes published a signed statement saying delivery was completed

Where from , you manage to derive this nonsense?

It might have been a poor choice of words.  I was referring to when emski said:

There should be no need for anyone except delegates to download bitcoin blockchain.

So by "two groups," I meant that in emski's proposal:

- Group 1:  Delegates download the Bitcoin blockchain and run some algorithm, to determine whether the BTC were delivered.
- Group 2:  Non-delegates do not download the Bitcoin blockchain, so they must use a different algorithm to determine whether the BTC were delivered.

I think it is safer to have every node run the same algorithm and check the BTC blockchain to determine whether the BTC were delivered.  (It is more resource intensive on all nodes, too, but I believe the security of users' funds is more important.)

Does that clear things up?

As well as , how did you come with the rest of your baseless conclusions, in other thread on this forum?

I've been posting a lot lately, in many different threads.  I have no idea what discussion you are referring to.

[theoretical]

btsx becomes spendable on transaction cancel or completion + possible dispute time 1-6 hours for example or depending on currency ONLY if we care that much for 51 delegate conspiration.

The other day I had a Bitcoin transaction take ~3 hours to be confirmed.  I wasn't doing anything weird, it was a totally normal payment to a single address (plus change address) generated by the Bitcoin core client.

If that happens, what does your proposal do?

My proposal requires the Bitcoin to be provably unconfirmable (based on the Bitcoin transaction's expiration time) before the BTSX blockchain is allowed to conclude it will not show up.

[tonyk]

btsx are unspendable in my proposal until transaction is canceled or completed

My understanding is your proposal was to divide nodes into two groups:

- Delegate nodes determine whether delivery was completed by examining the BTC blockchain
- Non-delegate nodes determine whether delivery was completed by checking if delegate nodes published a signed statement saying delivery was completed

Now if the delegates lie and say delivery was completed, when in fact it was not -- then the BTSX become spendable because all non-delegate nodes only validate the delegates' statement about what happened to the BTC, not what actually happened to the BTC.

In effect, you're making the delegates the final gatekeepers to those BTSX.  Currently, even if delegates collude and lie, they still cannot give your funds to anybody else unless you have signed a transaction authorizing it [1].  Your proposal opens the door to that being possible, and I am not comfortable with it.

[1] In the case of transactions in the currently implemented markets, the delegates cannot give your funds to a matching order without also giving you the consideration you demanded in your offer.  I.e. if you place an order to buy BitUSD with your BTSX, the only way the network can give your BTSX to someone else is if you get BitUSD in return, in the proportion you asked for.

Where from , you manage to derive this nonsense?
As well as , how did you come with the rest of your baseless conclusions, in other thread on this forum?

[emski]

There is no division of nodes in my proposal. It is the same situation as it is now. Only delegates matter.

btsx becomes spendable on transaction cancel or completion + possible dispute time 1-6 hours for example or depending on currency ONLY if we care that much for 51 delegate conspiration.

[theoretical]

btsx are unspendable in my proposal until transaction is canceled or completed

My understanding is your proposal was to divide nodes into two groups:

- Delegate nodes determine whether delivery was completed by examining the BTC blockchain
- Non-delegate nodes determine whether delivery was completed by checking if delegate nodes published a signed statement saying delivery was completed

Now if the delegates lie and say delivery was completed, when in fact it was not -- then the BTSX become spendable because all non-delegate nodes only validate the delegates' statement about what happened to the BTC, not what actually happened to the BTC.

In effect, you're making the delegates the final gatekeepers to those BTSX.  Currently, even if delegates collude and lie, they still cannot give your funds to anybody else unless you have signed a transaction authorizing it [1].  Your proposal opens the door to that being possible, and I am not comfortable with it.

[1] In the case of transactions in the currently implemented markets, the delegates cannot give your funds to a matching order without also giving you the consideration you demanded in your offer.  I.e. if you place an order to buy BitUSD with your BTSX, the only way the network can give your BTSX to someone else is if you get BitUSD in return, in the proportion you asked for.

[tonyk]

I am not sure I understood what is different in your proposal compared to mine

Not much, the money (BTC) go directly to the buyers account (If I understood they do not go there in yours (but in some delegate/escrow fund), might be a misunderstanding on my part).

In updated proposal btc go directly to buyer. No need for escrow. Just a fee goes to delegate on posting a bid.

And the first delegate to 'see' the BTC transfer on BTC blockchain just confirms includes the BTC/BTSX transaction on the BTSX  chain? Sounds good to me. (I have no opinion on the BTC forks issues, but I am sure you guys can figure it out)

[emski]

I am not sure I understood what is different in your proposal compared to mine

Not much, the money (BTC) go directly to the buyers account (If I understood they do not go there in yours (but in some delegate/escrow fund), might be a misunderstanding on my part).

In updated proposal btc go directly to buyer. No need for escrow. Just a fee goes to delegate on posting a bid.

[tonyk]

I am not sure I understood what is different in your proposal compared to mine

Not much, the money (BTC) go directly to the buyers account (If I understood they do not go there in yours (but in some delegate/escrow fund), might be a misunderstanding on my part).

[emski]

I am not sure I understood what is different in your proposal compared to mine

[tonyk]

As for the case when 51 delegates conspire - this is lack of consensus and require hard fork (just as any other type of misbehavior.  Nothing is different).

Such misbehavior is easy to prove and it is easily reversible - new delegates honoring the contract.

This is true in the current implementation, where the worst thing a 51 delegate attack can do is selectively deny service to some transactions.

Alice gets bitcoins from Eve.  Delegates claim Alice received BTC, so Eve gets Alice's BTSX.

Eve immediately cashes out the BTSX on BTER for Dogecoins.  BTER spreads the BTSX around to many other traders.

A few hours later, Alice is stirring up a storm on the forums and people evaluate the evidence, realize the delegates are untrustworthy, and an immediate hard fork is implemented.

A hardfork with a new group of delegates can't take anything away from Eve, her BTSX are long gone.  Returning the stolen BTSX descended from the illegal transaction would hurt the innocent third parties who unknowingly bought the stolen coins on an exchange.  Printing new BTSX to make Alice whole would simply be spreading the hit from the theft out to all BTSX holders through dilution.  Reverting the chain to the state before the theft would hurt merchants who delivered physical goods or other cryptocurrency in exchange for BTSX / BitAssets, only to see their balance evaporate when the chain reverted.

btsx are unspendable in my proposal until transaction is canceled or completed

In mine too.
Now, what don't you like in my changes. Why I am the only one spared?  :)

[emski]

As for the case when 51 delegates conspire - this is lack of consensus and require hard fork (just as any other type of misbehavior.  Nothing is different).

Such misbehavior is easy to prove and it is easily reversible - new delegates honoring the contract.

This is true in the current implementation, where the worst thing a 51 delegate attack can do is selectively deny service to some transactions.

Alice gets bitcoins from Eve.  Delegates claim Alice received BTC, so Eve gets Alice's BTSX.

Eve immediately cashes out the BTSX on BTER for Dogecoins.  BTER spreads the BTSX around to many other traders.

A few hours later, Alice is stirring up a storm on the forums and people evaluate the evidence, realize the delegates are untrustworthy, and an immediate hard fork is implemented.

A hardfork with a new group of delegates can't take anything away from Eve, her BTSX are long gone.  Returning the stolen BTSX descended from the illegal transaction would hurt the innocent third parties who unknowingly bought the stolen coins on an exchange.  Printing new BTSX to make Alice whole would simply be spreading the hit from the theft out to all BTSX holders through dilution.  Reverting the chain to the state before the theft would hurt merchants who delivered physical goods or other cryptocurrency in exchange for BTSX / BitAssets, only to see their balance evaporate when the chain reverted.

btsx are unspendable in my proposal until transaction is canceled or completed