(please excuse the length of this post..)

Currently there is an issue with ACCT.

You can't lose your coins, but it is very easy for a user to pull out of a trade, before it is complete, and just have both users keep their original coins. The 'Jamming'..

Many of us have come to the conclusion that some kind of central server, that still cannot steal your coins, could be used to help in the transaction.

..

Alex has 1 BTC, and wants to trade with BOB who has 100 LTC. (or whatever)

The Current Method :

2) Alex create a TXN that pays out 1 BTC to BOB, if he can provide the pre-image of a hash, that currently only Alex knows. There is also a refund element that allows Alex to reclaim the coins at some point in the future, lets say 24hrs later.

3) Alex posts this TXN, and BOB now has to wait for it to be 'fully' confirmed. He cannot publish his txn until this has happened.

4) Once the previous txn has cleared, Bob knows that if he knows the pre-image of a certain hash, he -AND ONLY HE- can claim the BTC. (until 24 hrs is up)

5) Bob creates a txn that pays out 100 LTC to Alex, if he can provide the pre-image of the same hash as his txn. This way when Alex claims his LTC, Bob can claim his BTC. (with refund bits etc..)

6) Bob posts his txn, and Alex now has to wait until it is fully confirmed, before he claims his prize, the LTC. Thus revealing the pre-image, and allowing Bob to claim his BTC.

There is no guarantee that Bob will publish his txn, as the price may have gone down, and if that happens both parties just get their coins back.

There is no guarantee that Alex will infact claim the LTC, by revealing the pre-image, as the price may have shot up!, and if that happens both parties just get their coins back.

..

To force Alex to reveal his pre-image I propose another txn be published.

Alex creates a txn that pays Alex say 5% of the original trade value, if he reveals the pre-image. And if he does not, after X amount of time, Bob can claim these coins. Lets call this the 'Hash-Force' (HF) txn.

SO in this case Alex would create a txn that pays 0.05 BTC to Alex(himself) if he reveals the pre-image, and using CLTV, after a few hours Bob can also claim those funds, if they have not been claimed already.

This would force Alex to either publish the pre-image, by claiming the coins, or not publishing and letting Bob take the 5% fee. An adequate recompense for not going through with the whole trade.

..

Now the tricky bit.

Alex of course CANNOT publish the HF txn until he is sure that Bob's txn has cleared, as otherwise he would have his original txn and his HF txn out in the wild and Bob would be able to either claim the original 1 BTC, or the 5% HF txn, without paying any LTC. Also there is little point to having the HF txn if he does wait as he may aswell just claim the original LTC coins, thus revealing the preimge that way, or not publishing anything anyway.

..

Let's bring in a central server. SERV.

New Method :

1) SERV, Alex and Bob, all generate a random string, S, A, B, and then hash it. These are H(S), H(A), and H(B). The pre-images are kept secret.

2) SERV asks BOTH Alex and Bob to send it a very specific txn.

Alex sends a BTC txn:

<txn>
    <1 BTC output>
           <PAYOUT If signed by Bob and A in H(A) and B in H(B)>
                            OR
           <PAYOUT If CLTV is 24hrs in the future and signed by Alex>
    </output>
    <0.05 BTC output>
            <PAYOUT if signed by Alex and A in H(A)>
                     OR
            <PAYOUT If CLTV 2 hours in the future and signed by Bob and S in H(S)>
    </output>
</txn>

Bob sends an LTC txn:

<txn>
    <100 LTC output>
           <PAYOUT If signed by Alex and A in H(A) and B in H(B)>
                            OR
           <PAYOUT If CLTV is 24hrs in the future and signed by Bob>
    </output>
    <5 LTC output>
            <PAYOUT if signed by Bob and B in H(B)>
                     OR
            <PAYOUT If CLTV 2 hours in the future and signed by Alex and S in H(S)>
    </output>
</txn>

Notice that the HF txn cannot be claimed by the other party, unless they know S in H(S). Which only the server knows.

3) Once the server has received BOTH txns, it publishes them. Both.

4) Once BOTH txns have cleared and are confirmed, the server shares the preimage of H(S), S, with both parties. Now both users HAVE to claim their HF txn, or lose the coins, and thus enable the whole trade to go through.

If BOTH txns do not clear the server does not reveal the S in H(S). Deletes it. This way noone can claim the HF, except the original author, and both parties just get their coins back.

If both txns clear, then the first one to claim their HF txn, reveals the preimage they know and allows the other party to claim their prize, aswell as their HF txn, and thus allow them both to claim their coins.

The 'Jamming' issue has now been relegated to one point, only at the very beginning, where one party could try and double spend their coins before they clear. In this case, and not knowing S in H(S), both parties would just get their coins back.

If either party does not provide their txn at the beginning, then neither txn is published, and no coins are jammed. It would be almost instant for the users to provide these TXNs, so if someone fails to do it, the server can just kick them out and move to the next user.

..

The Issue :

Everything works, EXCEPT if the server gets hacked. Then it is possible for one party to claim the HF txn, as they will know the S in H(S), and make sure that their txn is not published.

It is still not possible to steal the actual trade funds.

..

I am not sure if this can ever be made 100% atomic/safe.. can anyone think of anything (S in H(S) done differently)?

Making the HF txn 1% may make it less annoying (the server would have to be hacked after all, so I don't see this as a common occurrence..), but it's still not right..

Anyone ?

 

Actually BitShares is an 'onchain' exchange. What I mean is that the assets you trade are on the Bitshares Chain itself. This means the 'hack' does not work. But.. you have not really traded BTC for ETH.. You have traded a 'market pegged asset'.

When you want to trade BTC for ETH on BitShares, you actually trade a BTC 'token' against an ETH 'token' that both live on the BitShares Chain, and THEN have to convert those tokens, into either actual BTC or ETH.

So although the Chain itself is decentralised, and so is the trading, you still have to cash out, and this requires finding someone to exchange your BitShares tokens with.. hmm..

This is not the same as actually trading BTC you own, for real ETH. It's close-ish, but you are not sure you can even convert your 'tokens' into the real thing.

I think this is what prevents many of us from using onchain asset exchanges.. after all NXT has had one for-ever..

There is still NO SOLUTION to the 'Jamming' issue that affects decentralised exchanges..

So the other party can pull out before the trade is done should the market move against them ~30 minutes later (when they actually have to complete)

Until this TECHNICAL issue is resolved, I don't think any DLEX can really work..

The 'hack' is easy.

There's an order book, with 3 SELL orders below(at a lower price then) yours.

You initiate a trade with those three, to get them out of the way, never intending to complete.

New user turns up and sees your SELL order is the first available. Boom.

The ONLY 'hack-fix' at the moment is not decentralised, but centralised. Which kind of defeats the whole point.

..

It'll be some clever trick, like Tier Nolan's original and brilliant Atomic Cross Chain Transfer. No one's come up with it yet though..

hi - Like it.

Can we discuss the way Equibit pays out dividends ?

It says in the OP you can make a BTC denominated payment to Equibit shareholders.

How is this accomplished ? Who has access to the actual BTC ?

It can't be done by a majority vote of the Equibit stake holders - no ? Someone has to actually have the keys that access the BTC and will there need to be trust that he doesn't just run off with the money ?

Even if I own 95% of a certain company via Equibit, I have no access to the actual BTC coins ?

Or am i missing something ..

Wow.. I never thought I 'd say this (don't usually see you in this part of the world-as-we-know-it)... but I agree with MineCache.. {weird feeling}

( Although I choose not to use profanity.. you silly-billys.. )

Segwit currently at 54%..

http://luke.dashjr.org/programs/bitcoin/files/charts/services.html

So who is the 'minority' banning the 'majority' ?

It's a total 'no-brainer'. For lots of reasons.. Just tooo tired/bored to go through the whole bloody lot of them - again.. (And before you jump in Franky, I have looked at the code and run a node..)

I love POW vs POS.. 

I like POS consensus (a lot as it happens).. BUT..

The thing about a POS coin is that I can replicate the EXACT same security of a POS coin for nothing. And this is really the ONLY thing that gives a coin it's value.

Say there is a network of 100 nodes, securing a POS coin.

I can get 100 computers, copy the coin distribution, and run it with EXACTLY the same security. No problem.

I cannot do that with a POW coin. (you need all the ASIC/Hashing hardware)

I think POS definitely has a place, but it's not as a PUBLIC coin. It's FAR MORE USEFUL as a group/organisation/company PRIVATE tool. Where the value is ONLY relevant to the people running that particular network. Like a private ETH chain(once POS introduced) running the company as a DAO.

POS is a tool. Like Email is a tool. Anyone should be able to use it.

Saying GMAIL's protocol is 'inherently' more valuable than HOTMAIL/YAHOOMAIL etc etc or any other email provider just doesn't make sense.

..the thought of that turns me on..

..eh ?

You such a 'hater' lately - Frank. 

Was the $1 billion dollars stolen from MtGOX an 'over hyped exaggeration' ?

I know - sloppy code. Well - what if every other exchange out there, (with BUCKETS of code complicating things trying to get around txn malleability), could now NOT worry about that issue, and simplify their withdrawal process by a factor of, I dunno, 100 ? Pretty useful if you ask me. (And I actually write code for an exchange)

..I could go on.. (there's almost too much).. but I know you're going to lay into this post whatever I say.. 

Yo Jet!

I wouldn't play with the block time.

I would do this though..

1) Create your blocks as normal.

2) Now create a 'transmission-block' that only has the txn hashes in it, not the whole txn. The txns are MOST LIKELY already propagated throughout the network, and the small percentage that aren't known to your peers, can be passed on 'at-the-point-where-you-pass-the-block-on'. No need to send them twice.

3) Transmit the TINY transmission block (32 byte per txn). (plus a small amount of 'extra' data to help in the recreation of the full block, full-block hash etc.. to check)

4) Those that get the trans-block, can recreate the full-block, check it against the hash sent in the extra data, and proceed as normal.

boom. Tiny blocks. 1MB at 32 bytes per txn, could hold.. ~30000 txns / block.

 

.. hmmm..

no - I'm afraid it's not.

ANYONE can use SEGWIT / LIGHTNING NETWORK / SIDECHAINS / OFF-CHAIN scaling solution. A.N.Y.O.N.E.

It is OPEN SOURCE.

It is NOT PROPRIETARY.

I'll admit - It is quite complicated (to set up an LN network / Sidechain), and requires SKILL / KNOWLEDGE, and yes, if you wanted someone to set it up for you, Blocksteam would be my first choice. Is that a crime now ?

so please.. '..It's a little early in the morning for Kung Fu..'

..

@OP - Can you come up with a FIX for txn malleability (the root of MANY issues) ? If you can, I'm all ears.

FFS.. silly nonsense.

Hang in there GMAX.

Like ByteBall ?

I'd say that there will be A LOT of un-pruneable data to verify the txn.

I've been working on a system that does exactly this, and the issue arises because instead of storing the UTXO (unspent) you have to store the STXO (spent), which is much MUCH more data.

I do like it, but want to come up with a version that doesn't grow to infinity..

Bitcoin Unlimited is a relatively easy concept. Anyone could code it.. so you don't really need a dedicated dev team. It's the idea that matters.

A BU node has 2 parameters that the miner can specify.

'max-build-size' and 'see-if-it-works-size'. 'see-if-it-works-size' is the bigger and it is meant to see if the rest of the network will accept a block before you do as well.

When they receive a block they check the size and..

1) If the size is less than or equal to the 'max-block-size' they have specified for themselves, they start building on it AND forward it to the network.

2) If the size is greater than their 'max-build size' but LESS than the 'see-if-it-works-size' they have specified for themselves, they ONLY forward it to the network (but don't build on it - until a majority of the network is working on it).

3) If it is more than both the 'max-build-size' and the 'see-if-it-works-size' they don't build AND don't forward it (ignore it completely).

That's it. (basically)

--

Do I support it.. almost. I like the idea of a decentralised mechanism for determining the block size, but this way may cause issues.. can we be trusted to NOT fuck this up.. ?  (And you have to be pretty bad ass to tell #GMAX to stick it.)

Hashing is so coool.. 

Confidential Hash Based TXN Chains does something similar..

https://bitcointalk.org/index.php?topic=1298588.0

It only hashes the values.. not the whole TXN, BUT does not need to grow indefinitely (pruneable).

I know you're not, but I'm glad you're back, Anonymint TBTP iamnotback..

Always enjoy squinting and leaning forward to read your 'light' posts.. (and invariably scratching my head)..

Can you explain that Artic ? How could block size affect the total number of coins ?


I respectfully disagree..

There are many solutions to 'full' pruning that we could implement at a later date. So size of Storage is a non-issue. We could remove all the txns and only keep the UTXO for one. (I know this has implications, but since we are going Segwit anyway, and losing the signatures, the spent txns seem less important now)

As for the Bandwidth required and latency involved in transmitting the blocks, they could put ONLY the txn hash in the block, not the whole txn. (the txn will have been sent across the network already.) So a bump to 2 or 3 megabytes may be ALL that is ever required. Since once the txn hash and not the whole txn is added to the block, the capacity in a single block will jump to 10x-100x more.. at the same size..

Not to be contentious.. but your previous post about bitcoin Unlimited, and the Free market, seems the way to go for me.. The Problem with that is that the miner does risk losing his block reward if he tries to build a chain with a block size that the rest of the network doesn't accept.

The 3 options a miner has are :

1) Don't forward a block. (Block size too big)

2) Forward a block, but don't personally build on it. (Block size big, but you are prepared to see if someone else builds on it)

3) Forward and build on it. (Block size just right, you build on it)

Other than the risk of losing your reward, this is a nice setup. Need to find a clever fix though.. like if you were using a GHOST chain, and orphaned blocks were also paid. (Since in GHOST they would still add to the overall 'weight' of the chain)

That might be interesting.

Not sure that's going to work.

When you mine you have to hash a block header with a random nonce. The block header has the hash of the previous block. The Previous block hash will be different for the different chains.

So you cannot mine multiple chains at once.. as your header will either point to one block or another, and you can't solve for 'both' (you can in POS, but not in POW)

They ALL need to be in on it, or they can't cheat.

I think the likely-hood of that is 'almost' zero.

I'm more concerned that a bug is found in the protocol, and that coins can be created, without anybody knowing..