0 Members and 1 Guest are viewing this topic.
Quote from: tonyk on September 14, 2014, 04:01:49 amQuote from: drltc on September 14, 2014, 02:08:56 amMy 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 completedWhere from , you manage to derive this nonsense?It might have been a poor choice of words. I was referring to when emski said:Quote from: emski on September 12, 2014, 05:32:05 pmThere 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?Quote from: tonyk on September 14, 2014, 04:01:49 amAs 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.
Quote from: drltc on September 14, 2014, 02:08:56 amMy 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 completedWhere from , you manage to derive this nonsense?
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
There should be no need for anyone except delegates to download bitcoin blockchain.
As well as , how did you come with the rest of your baseless conclusions, in other thread on this forum?
Quote from: emski on September 14, 2014, 03:30:00 ambtsx 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.
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.
I've been posting a lot lately, in many different threads. I have no idea what discussion you are referring to.
Quote from: emski on September 14, 2014, 01:30:27 ambtsx are unspendable in my proposal until transaction is canceled or completedMy 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 completedNow 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.
btsx are unspendable in my proposal until transaction is canceled or completed
Quote from: tonyk on September 14, 2014, 01:40:50 amQuote from: emski on September 14, 2014, 01:36:01 amI am not sure I understood what is different in your proposal compared to mineNot 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.
Quote from: emski on September 14, 2014, 01:36:01 amI am not sure I understood what is different in your proposal compared to mineNot 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).
I am not sure I understood what is different in your proposal compared to mine
Quote from: drltc on September 14, 2014, 01:17:21 amQuote from: emski on September 14, 2014, 12:55:13 amAs 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
Quote from: emski on September 14, 2014, 12:55:13 amAs 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.
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.
Quote from: drltc on September 13, 2014, 06:46:42 pmSo what if we had a system where you only pay the huge fee temporarily, then get it refunded when you actually deliver, so the only one who actually pays the fee is someone whose BTC never shows up?It sounds pretty good...in fact, that's exactly what I proposed in the first place Yeah, makes sense to me.
So what if we had a system where you only pay the huge fee temporarily, then get it refunded when you actually deliver, so the only one who actually pays the fee is someone whose BTC never shows up?It sounds pretty good...in fact, that's exactly what I proposed in the first place
Quote from: emski on September 13, 2014, 11:11:57 amI also think that supporting as much as possible cryptocurrencies is better option than BTC only. The only heavyllifting will be done by delegates and they should decide how much alts should be supported.I think that part of your proposal gives too much power to delegates. As it is, even the largest collusion of delegates can only do denial-of-service on the network, right now they cannot e.g. give Alice's BitBTC to Eve -- even if all 101 delegates agree that should happen, it will not unless there's a signed transaction from Alice. But if only delegates validate the BTC blockchain, then a majority of delegates can collude to claim Eve delivered BTC in fulfillment of Alice's order, when in fact Eve did no such thing.All nodes should validate any transactions that cause funds to change hands instead of just trusting the delegates. Since the whole "delegate" thing is itself very new, we should be conservative in what we allow delegates to do.I agree that supporting more cryptocurrencies will add benefit, but storing and validating another blockchain will also impose costs on all nodes that validate BTC transactions. Having all nodes validate makes this cost burden greater, but I think the security of the network is more important than reducing nodes' costs. Which logically leads to the conclusion that we should only allow the most limited set of cryptocurrencies -- perhaps only one. And if we only support one, that one should obviously be BTC.
I also think that supporting as much as possible cryptocurrencies is better option than BTC only. The only heavyllifting will be done by delegates and they should decide how much alts should be supported.
sounds like a nice idea. But it seems more like an implementation detail right now, as nobody has started implementing this yet..
Quote from: tonyk on September 13, 2014, 05:54:24 pm- What would happen if Eve makes a Bid order (or many Bid orders from different addresses) that offers 1,000,000 BTC and matches the whole Ask book (which Eve has no intention of paying)?I think Eve losses his transaction fees after 5 BTC blocks - i.e. no problem except for about one hour.So anyone would be able to shut down the whole market indefinitely, at a cost of one transaction fee per hour. That sounds secure... [/sarcasm]Unless we make tx fees huge. Then fiduciary exchanges like BTER or MtGox take all the customers because they can offer way smaller fees.So what if we had a system where you only pay the huge fee temporarily, then get it refunded when you actually deliver, so the only one who actually pays the fee is someone whose BTC never shows up?It sounds pretty good...in fact, that's exactly what I proposed in the first place
- What would happen if Eve makes a Bid order (or many Bid orders from different addresses) that offers 1,000,000 BTC and matches the whole Ask book (which Eve has no intention of paying)?I think Eve losses his transaction fees after 5 BTC blocks - i.e. no problem except for about one hour.
Quote from: tonyk on September 13, 2014, 05:10:55 pmCouldn't the delegates just monitor if the BTC has arrived in the BTSX seller account (BTC address) directly:- If no(at least unconfirmed) after say 5 BTC blocks - free-up the BTSX held (in kind of collateral if you would like), and re-activate the buy BTC order.- If yes //BTC - sign the transaction sending the BTSX to the BTC seller.I think you're mixing up "buy" and "sell". I think your proposal is basically equivalent to what I propose.But consider:- What would happen if Eve makes a Bid order (or many Bid orders from different addresses) that offers 1,000,000 BTC and matches the whole Ask book (which Eve has no intention of paying)?- What would happen if there is a BTC fork which ultimately results in transferring Bob's BTC to Alice, after the delegates have decided Bob won't deliver and free up Alice's order to go to someone else?This is why I say the buyer must be bonded, and the order must remain matched until you can prove delivery can never happen (barring a BTC fork longer than REQUIRED_CONFIRMATION_COUNT blocks).
Couldn't the delegates just monitor if the BTC has arrived in the BTSX seller account (BTC address) directly:- If no(at least unconfirmed) after say 5 BTC blocks - free-up the BTSX held (in kind of collateral if you would like), and re-activate the buy BTC order.- If yes //BTC - sign the transaction sending the BTSX to the BTC seller.
I prefer not to use trading in increments in the form you proposed. I think that the better option is market solution where the willingnes for an exchange (BTC->BTSX) is expressed in BitsharesX blockchain. Then market fees/bonds paid in both blockchains. Then BTC holder makes payment. And then delegates ensure contract fulfillment on BitsharesX blockchain.
@emskii like the idea, but it looks to complicatedwhat about something like thiswe need a bitAsset buyBTSXwithBTC or something1. BTSX holders can publish to which price they are willing to buy BTC and to which address the transaction has to be made (maybe connect it with a pricefeed form BTER)- like something i am willing to sell 100.000 BTSX for 0.00008022 recieved from BTER (the latest price not a static price but maybe rescan every 30 sec)2. Richy only needs to buy my offer on the BTSX exchange3. now the exchanges waits for an transfer within 3 hours of his BTC to my BTC address i attached with my order placement - the networks blocks my BTSX (takes it as a colleteral)4. after the BTSX networks confirms the transfer in the bitcoin network it will release the collateralised BTSX so we would need "only"1. a bitAsset you could only buy but not sell2. a service who is checking the bitcoinblockchain for this kind of transferwhat do you think? hope i explained it undestandablein my opinion it is much easier and simpler and could be implimented via I3 .
I think we should use Gateways. Push IOUs to the Gateways. You can use delegates if delegates would like to deal with whatever possible licensing then it will be fine. Nothing stops a delegate from being a money exchange company.
I'm sure most would agree with the objective. How to accomplish the objective is the big question. Questions that come to my mind are:1. What is the best technical approach ?2. Are there any potential legal risks for delegates ?3. How does this fit or not fit with what BM has planned?Does anyone know what BM thinks about this?
It sounds like something that a third party provider could create. Why not give it a try? Pretty soon, BitShares itself won't be able to cover all these bases at once with limited programming support. People will realize that legitimate business opportunities (not just DACs) exist in these outside niches, and meeting demand in these areas still can benefit the overall BitShares ecosystem.
I've actually been thinking about a similar scheme. The problem with your scheme is it turns the delegates into fiduciaries, they are responsible for manually sending the bidder's BTC. This may subject delegates to regulatory scrutiny.I would be most comfortable with having the bond be paid in BTSX or some BitAsset. In that case we can just add logic to the BitSharesX blockchain to compensate the Ask order if the BTC's don't show up. Thus we no longer place responsibility on a single delegate -- it is enforced at the same level as a blockchain as a whole. However, this would mean that someone with only BTC can't enter the ecosystem, and you point out that this is an important use case.Because any of this would require all nodes to run a Bitcoin daemon as well (or otherwise talk to the Bitcoin blockchain) in order to validate the delegates' actions, I am thinking this should probably be a new BTSX child blockchain (BitShares Y perhaps?)
VERY relatedcrosspost:https://bitsharestalk.org/index.php?topic=8762.0
So what, burn btc for btsx?