Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - complexring

Pages: 1 [2] 3 4 5
16
General Discussion / Re: Graphene: Data security and verification on the chain
« on: February 13, 2016, 04:20:43 am »
Quote from: BunkerChain Labs on February 13, 2016, 04:04:42 am
Quote from: JonnyBitcoin on February 13, 2016, 03:27:45 am
@complexring  @BunkerChain Labs
Your question is: when SIDEBTC is transferred the previous owner will still have the public key so its not secure.

This is how it works, there a 3 types of BTC
1. real BTC
2. SIDEBTC
3. BITBTC (like current bitbtc but collatralised 1:1 with side btc)

So SIDEBTC cannot be transfered ever. The owner of it uses it as collateral to create BITBTC which can be transfered.

The user doesn't need a private key.. thats where everyone seems stuck.

Just for a simple example it can be done where there is a BTC address for Bitshares with a required memo of your username in Bitshares.

Once the deposit is confirmed by the witnesses and secured among them with multi-sig then the user account is credited SIDEBTC SBA identical to what was deposited. At that point it is just like any other asset on the system but of course with the 100% collateral backing of the BTC that is now locked in the Bitshares network.

If someone wants to transfer their BTC OUT of Bitshares, well there are a few existing bridges already available, but if we want to, we can simply allow any holder of the SBA to be able to send it from our ledger which will then send a transfer cmd to the witnesses to then send X amount of the bitcoin to the address specified and once confirmed burn the SIDEBTC SBA.

That's about all these is too it.

Sure.  I am not stuck on the concept of a pseudo-sidechain with the witnesses having the necessary private keys to unlock a multisig address.  I think that this is a fairly decent solution if we want to go that route.

The original post was linking to the Enigma article about using a decentralized homomorphic encryption scheme and it was suggested in this article that it would be possible to store a private key on the blockchain (in some manner).  This would move us from having centralized trusted parties, i.e. the witnesses, to a true trustless sidechain possibility.

The other option, which goes along nicely with @bytemaster's blog on why he likes Ethereum, is to have a smart contract in such a way that allows for a 'dynamic' address, as mused in a previous post.

17
General Discussion / Re: Graphene: Data security and verification on the chain
« on: February 13, 2016, 04:15:56 am »
Quote from: JonnyBitcoin on February 13, 2016, 04:00:02 am
Quote from: complexring on February 13, 2016, 03:39:37 am
Quote from: JonnyBitcoin on February 13, 2016, 03:27:45 am
@complexring  @BunkerChain Labs
Your question is: when SIDEBTC is transferred the previous owner will still have the public key so its not secure.

This is how it works, there a 3 types of BTC
1. real BTC
2. SIDEBTC
3. BITBTC (like current bitbtc but collatralised 1:1 with side btc)

So SIDEBTC cannot be transfered ever. The owner of it uses it as collateral to create BITBTC which can be transfered.

So SIDE.BTC (or SIDEBTC, or whatever) will be non-transferrable and will be the underlying collateral for BITBTC.  But then, there could be instances of the original depositor not logging in and not being able to approve a transaction, or just choosing not to do that (for whatever nefarious reason).  Sure, this attack causes them to lose out on the btc that was originally deposited, but they sold for some other asset, say maybe bitEURO, bitCNY, or bitUSD, and are able to withdraw out of the DEX in this manner.  The person who now owns BITBTC will be out if that user ever wants to withdraw bitcoin and hold in their own long-term wallet.

`Transferring` of the private keys must be done in some manner.  Either by moving the bitcoin to a new multisig address each time for each new holder of the underlying asset (inefficient) or, better yet, a(n improved notion of a) smart contract, that is like a dynamic multisig and can be turned on or off when certain conditions are met, i.e. think of it as approving or revoking the signing of a transaction in a regular multisig transaction, but that is done in a trustless manner via the code.  Essentially, program in 'dynamic' addresses where they are spendable if a certain condition is met even if you have the 1 private key that can be used to unlock it, you can't transfer out since you haven't met the appropriate conditions.

This latter solution, if possible, would be great!  I'm not entirely sure how the implementation of smart contracts or the design of them is actually done.  But if this type of dynamic solution isn't already considered, this is a huge improvement!

The bitbtc can move freely and doesn't need the original depositors signature. just like bitbtc currently works.
The new holder of bitbtc will not be able to force settle the bitbtc for real btc but they will be able to sell to someone else 1:1
i see what you mean though. You could discourage this by demanding collateral of 105% instead of 100%

Sure.  I understand bitbtc can be freely moveable and sidebtc is not.  However, the issue still remains if a user who owns bitbtc (or bit(altnamehere)) wants to move out of the system and have the actual cryptotoken in their possession.  We can't rely on the original depositor to always be online to approve a transaction and or to always be honest.

Even if they have an extra 5% collateral that would be needed, I still don't think that this solves the problem.

I concede that the scenario of a dishonest depositor seems unlikely due to the additional 5% penalty and I wouldn't expect a 'rational agent' to behave in that manner.  People are rarely rational, unfortunately, and (most) game theory assumes agents will act in a manner that promotes their own self-interest. 

Even in the case of an honest depositor, what happens when the original depositor is dead and / or loses their private key ? That collateral is locked up forever and there is no way of removing it from the system.  In addition, since the collateral can't actually move, can it really be seen as collateral anymore? I would think not.

18
General Discussion / Re: Graphene: Data security and verification on the chain
« on: February 13, 2016, 03:39:37 am »
Quote from: JonnyBitcoin on February 13, 2016, 03:27:45 am
@complexring  @BunkerChain Labs
Your question is: when SIDEBTC is transferred the previous owner will still have the public key so its not secure.

This is how it works, there a 3 types of BTC
1. real BTC
2. SIDEBTC
3. BITBTC (like current bitbtc but collatralised 1:1 with side btc)

So SIDEBTC cannot be transfered ever. The owner of it uses it as collateral to create BITBTC which can be transfered.

So SIDE.BTC (or SIDEBTC, or whatever) will be non-transferrable and will be the underlying collateral for BITBTC.  But then, there could be instances of the original depositor not logging in and not being able to approve a transaction, or just choosing not to do that (for whatever nefarious reason).  Sure, this attack causes them to lose out on the btc that was originally deposited, but they sold for some other asset, say maybe bitEURO, bitCNY, or bitUSD, and are able to withdraw out of the DEX in this manner.  The person who now owns BITBTC will be out if that user ever wants to withdraw bitcoin and hold in their own long-term wallet.

`Transferring` of the private keys must be done in some manner.  Either by moving the bitcoin to a new multisig address each time for each new holder of the underlying asset (inefficient) or, better yet, a(n improved notion of a) smart contract, that is like a dynamic multisig and can be turned on or off when certain conditions are met, i.e. think of it as approving or revoking the signing of a transaction in a regular multisig transaction, but that is done in a trustless manner via the code.  Essentially, program in 'dynamic' addresses where they are spendable if a certain condition is met even if you have the 1 private key that can be used to unlock it, you can't transfer out since you haven't met the appropriate conditions.

This latter solution, if possible, would be great!  I'm not entirely sure how the implementation of smart contracts or the design of them is actually done.  But if this type of dynamic solution isn't already considered, this is a huge improvement!

19
General Discussion / Re: Graphene: Data security and verification on the chain
« on: February 13, 2016, 03:18:40 am »
Quote from: JonnyBitcoin on February 13, 2016, 01:20:58 am
@noisy I have taken what i think you are getting at and changed it a bit. I think this could work?? @xeroc  @tbone @complexring @abit @JonnyBitcoin @brainbug @Shentist @Akado @TravelsAsia @BunkerChain Labs @merivercap @btswildpig @fuzzy @bytemaster

Bitshares generates a 2 of 2 multisig bitcoin address. 1 of these signitures is held by the witnesses. The other signature is held by the bitshares users account.
The user deposits bitcoin to this new btc account and will only be able to retrieve it when the witnesses provide the other key.
Bitshares then generates a sideBTC token for the user.
The user can then use this SIDEBTC as collateral to create BITBTC.  but they will only need 100% collateral and have zero risk of margin call or force settlement.

To regain access to his realbtc he will need to repay all debts. Bitshares the destroys  the SIDEBTC token and allows access to the real BTC by getting the witnesses to sign with the second key.

OK.  So here we have a 2 of 2 multisig address.  Witnesses collectively control 1 of the 2 keys and the original depositor controls the other.

Where is this other private key held?  Locally on the other users HD space or do we suggest using an implemented form of Enigma's design for decentralized operations on encrypted data?

What happens when the user sells his BITBTC asset?  The user still has access to the private key, which is fine, since it should be noted by the network that he no longer has that asset anymore and the witnesses won't grant him withdrawal access if he attempts to do so using the command line operations.

But, we still have an issue if the original depositor is one of the witnesses (as was noted earlier in the thread).  I suppose that this could be noted in the code if a depositor is a witness, they don't get that 2nd key access.  However, this doesn't prevent a witness from creating a different account and performing this type of attack.

In addition, when the original depositor sells his token, the user in some way needs to pass the private key to the next holder of that asset.  How is this done ? 

Maybe there's a way to do this in a 'smart contract' manner.  The smart contract could be executed when the underlying asset is sent to a particular address.  In the memo could be the address where the underlying collateral should be sent.  Then, the smart contract is executed when this happens and releases the funds to the right address.

Can this be done in a way that is still trustless? 


20
General Discussion / Re: Is it possible for bitshares to become a sidechain of bitcoin?
« on: February 13, 2016, 12:33:27 am »
Quote from: noisy on February 12, 2016, 08:46:02 pm
@tbone @complexring @abit @JonnyBitcoin @brainbug @Shentist @Akado @TravelsAsia @BunkerChain Labs @merivercap @btswildpig @fuzzy

a solution?

https://bitsharestalk.org/index.php/topic,21438.msg278789.html

potentially.  it's some pretty awesome math (and computer science) backing it up.  :o

21
General Discussion / Re: Graphene: Data security and verification on the chain
« on: February 13, 2016, 12:30:18 am »
i am unsure how one can effectively store a private key on a permissioned blockchain.  someone has to have access to this at some level.  or am i missing something? whomever would have this access would be able to read the private key and thus have access.  i suppose, you could do the 2 of 2 multisignature address option.  but, each time that the associate sidechain's asset is sold on the dex, you'd have to move it to another multisig address where the new holder of the asset would have the new private key.  if you do this often enough (and why wouldn't you?), then the amount will be eaten by the btc transaction fee, which could presumably be passed to the buyer each time ... but the whole process becomes cumbersome.

also, the whole notion of being able to do effective computations on encrypted data is a very hot topic in the mathematics and computer science academic world and the notion is known as homomorphic encryption.  the main disadvantage of homomorphic encryption is that it's uber-slow, i.e. the number of computations that it takes for any known scheme so far is infeasible for real world applications.  this is getting better, since hardware is improving, but applications that will be able to do computations in real-time are in the (near?) future.

that is a great paper that you referenced!  basically, it does the homomorphic encryption, but in a decentralized manner and then uses the spdz protocol to ensure an audit trail of the computations in a public manner, unless i misunderstood the whole point of it.  i need to read it again (probably 5 or 6 times) before i grasp the entirety of the algorithms. 

very nice ... very nice indeed ....

22
General Discussion / Re: Is it possible for bitshares to become a sidechain of bitcoin?
« on: February 05, 2016, 05:22:13 am »
Quote from: abit on February 04, 2016, 06:24:04 pm
Quote from: complexring on February 04, 2016, 04:01:06 pm
Quote from: abit on February 04, 2016, 08:33:01 am
TL;DR Don't know whether this be considered in the thread yet:
 If we want to automatically have top 15 witnesses multi-sig the BTC wallet, we need to improve voting participation first, otherwise for example btc38 would be able to steal the fund easily.

Please look up and read my solution regarding choosing a random 15 of the delegates to be holders of a multisignature address.  I think there's the possibility of 'revolution' type events where the top 15 could be voted out, and with them, the associated keys to the multisignature addresses.
I feel that we don't need "active" witnesses to sign btc and/or in-bts-btc transactions, actually any witness_node can do that, they just need to broadcast transactions, active witnesses will then get them into blocks. So some random algorithm makes sense.

//Update:
With my "heart-beat" proposal, it's possible to identify which witness is alive.

However, with randomly selected witnesses, we can't not prevent an attacker from running thousands of witness_nodes so that increasing chance of having all keys. I think some kind of PoW based witness selecting may work.

Ok. Good. It seems, then, that we need to prevent both possibilities:

1) an attacker from running thousands of witness_nodes to gain the private keys
2) a kick the bums out event where the top witnesses who have keys are voted out, and too many are voted out at once


23
General Discussion / Re: Is it possible for bitshares to become a sidechain of bitcoin?
« on: February 04, 2016, 04:01:06 pm »
Quote from: abit on February 04, 2016, 08:33:01 am
TL;DR Don't know whether this be considered in the thread yet:
 If we want to automatically have top 15 witnesses multi-sig the BTC wallet, we need to improve voting participation first, otherwise for example btc38 would be able to steal the fund easily.

Please look up and read my solution regarding choosing a random 15 of the delegates to be holders of a multisignature address.  I think there's the possibility of 'revolution' type events where the top 15 could be voted out, and with them, the associated keys to the multisignature addresses.

24
General Discussion / Re: Is it possible for bitshares to become a sidechain of bitcoin?
« on: February 04, 2016, 05:49:55 am »
Quote from: betax on February 04, 2016, 04:22:21 am
Instead of witnesses cannot be done in a public way (specialised witnesses) by businesses. In a similar way I would like an easy way to adjust the asset issue balance between Bitshares and Ethereum, so assets can be transferred back and forth at a minimal cost for the end user.

This is what @Shentist was suggesting.  And I say, why not allow businesses to form partnerships AND do this with voted witnesses.  Both have merit.  One allows, as you put it, minimal transferrance between other networks via businesses holding private keys, whereas the other encourages adoption and usage of the BitShares network.

25
General Discussion / Re: Is it possible for bitshares to become a sidechain of bitcoin?
« on: February 03, 2016, 07:11:35 pm »
Quote from: noisy on February 03, 2016, 03:20:17 pm
Quote from: bytemaster on February 02, 2016, 10:10:12 pm

1. Have all of the witnesses monitor the BTC network for transfers to a designated multi-sig address which is defined by the BTS consensus to be the top 15 witness signatures (max MSIG allowed by BTC).   All of these UNSPENT OUTPUTS get included as part of BTS consensus state.


Ok, I have few questions:

1. how those 15 signatures will be distributed among witnesses? What will happen if some witness lose their key? (I doubt that mine understanding of this is correct... )

Or...

2. those 15 signatures will be somehow encrypted in the bitshares blockchain? Is that correct that then most of the witnesses (by voting power) will need to agree to use those 15 signatures to make a transaction?

Assuming, that this above is correct, why we need to use 15 signature if those signatures can be used only if witnesses will have consensus? We we cannot use 10, 2 or 1?

Is that means, that bitshares network itself will have to prove, that we have all signatures needed to make a transaction? How does it work? Is those multiple signatures has to be combined into one? (I doubt it.. because that will mean, that single request from some computer will have to be made, and that computer can intercept this precious key).

Is that mean, that bitshares network will have to prove that we have all 15 signatures? One witness will "authenticate" one signature? How network will assure, that after some time some witness will not collect all signatures? Is that mean, that network will have to prevent that one specific witness will never authenticate more than one signature? What if over time someone will gather 15 signatures by 15 different witnesses?


Disclaimer: my questions probably are silly and I guess I made quite few completely wrong assumptions, nevertheless, it would be great if someone could share more details about possible implementations of that.

I don't think these are silly questions at all.

Multisignature addresses, in general, work on the M of N notion, where there are N total signing keys and only M are needed to approve a transaction.

M and N are values passed when the multisignature address is created.

I'm not entirely sure all the details of how this will work as witnesses are voted in and out.  I imagine that as long as there is no sudden 'revolution', i.e. a situation where some number of top witnesses get voted out from the top 15 and there are no longer enough to approve a transaction, this may pose a problem.

Perhaps the way to do that is to randomly choose 15 from all the witnesses.  This gives a 'revolution' type voting event more stability in that it's probably unlikely that all will be removed completely from being witnesses.  But I could see a situation where if we use 8 of 15 multisignature addresses that at least 8 could move from being in the top 15 to the top 30, in which case, there's no 'good' way of handling transferring of keys.  If we instead allow for a 'random' choice of all the witnesses, we won't have this type of situation. 

Point being, with 37 witnesses (unsure the total number now), and choose 15 out of those, that is 37!/(15!12!) = LARGE NUMBER, whereas 15 choose 15 is precisely 1.  So, we've reduced risk that a revolution event of voting out enough witnesses who are needed for the multisig address actually occurs.

As Shentist mentioned, this is what MetaExchange does with the META.BTC user issued asset.  He brings up a good point that this hurts his business model.  In a way, there's no reason why Meta and Blocktrade and any other entity could do the same thing, without the necessity for witnesses, etc.  Collusion, once more, could happen.  But if people are already trusting them now with their UIAs, this shouldn't pose a large problem.

In fact, I encourage both solutions, Meta, Blocktrade, etc. collective multisig wallets and random 15 witnesses multisig wallets.  There is nothing that says these models are mutually exclusive.

26
Technical Support / Re: Compilng UI -- 2.0.160127
« on: February 03, 2016, 05:26:02 pm »
Quote from: svk on February 03, 2016, 06:19:27 am
Thanks for the detailed breakdown, I'll go over the dependencies and instructions again to see if I can make it easier to get started.

You only really need the web and dl folders, the rest are unused by the GUI itself and probably very out of date like you discovered.

No problem.  Good to know that only web and dl folders are needed.

Glad to be of assistance.

27
Technical Support / Re: Compilng UI -- 2.0.160127
« on: February 03, 2016, 05:25:04 am »
OK.

After trying to read through the npm error messages, I attempted to install the 'peer dependencies' necessary.

I kept getting errors until I realized I needed 'node' in my path and could not just do an absolute call to npm and expect that version of npm to use the node installed in that folder.

Once I added the node binary to the PATH environment variable, I began to install the various dependencies, I reran 'npm install' again in the web folder.

This was all to no avail ... so I went back to the documentation again and installed nvm and am using the latest node (v5) and npm.

Anyway, after re-downloading a fresh copy of the ui github repo and then switching to the branch 2.0.160127, I begin the procedures again, after removing the previous node / npm from my path and using the ones that are now being managed by nvm.

All well and good, except for when I tried to run 'npm install' in the cli folder.

I get an error that there was an unmet dependency with the coffee-loader needing coffee-script@1.x. 

So, I go ahead and manually install coffee-script@1.x into the corresponding folder using

npm install coffee-script@1.x

Thinking that this would work and now I can install the cli folder properly, I try

npm install

but this fails.  So, out of nothing more than sheer trial and error, I go ahead and decide to install coffee-loader manually, thinking that maybe

npm install

does something where it re-writes any other manually installed package (still unsure what is actually done with npm and the packages installed in node_modules, especially since coffee-loader is a dependency in the package.json file).

Anyway, after doing

npm install coffee-script@1.x ; npm install coffee-loader ; npm install

I do not get any peer dependency errors for the cli folder.

The 'dl', 'ios', and 'web' folders both work just fine with 'npm install'.

Then, the 'npm start' worked fine in the web folder. 

Not sure what was going on in the cli folder like that ...

Sorry for the ramblings on what I did -- what failed to work -- and what eventually succeeded.

New design looks great, btw!

Also glad to be running the latest locally.

28
Technical Support / Compilng UI -- 2.0.160127
« on: February 03, 2016, 03:58:44 am »
Hello,

I have recently decided to update my local version of the UI.  I am running into some errors when performing 'npm install' in the web folder.

The following, I believe, is the relevant error in the debug file:

-------------

36862 error Darwin 15.0.0
36863 error argv "/usr/local/node/0.12.2/bin/node" "/usr/local/node/0.12.2/bin/npm" "-g" "install"
36864 error node v0.12.2
36865 error npm  v2.7.4
36866 error code EPEERINVALID
36867 error peerinvalid The package react does not satisfy its siblings' peerDependencies requirements!
36867 error peerinvalid Peer react-foundation-apps@0.7.0 wants react@>=0.14.x
36867 error peerinvalid Peer react-highcharts@2.1.0 wants react@*
36867 error peerinvalid Peer react-interpolate-component@0.7.1 wants react@>=0.12.1 && <0.14.*
36867 error peerinvalid Peer react-json-inspector@5.0.3 wants react@^0.13.0
36867 error peerinvalid Peer react-motion@0.3.1 wants react@>=0.13.2 || ^0.14
36867 error peerinvalid Peer react-router@0.13.3 wants react@0.13.x
36867 error peerinvalid Peer react-tooltip@0.6.4 wants react@>=0.13.1
36867 error peerinvalid Peer react-translate-component@0.9.0 wants react@>=0.12.1 && <0.14.*
36867 error peerinvalid Peer react-dom@0.14.7 wants react@^0.14.7

-----


Note that I have node v0.12.2 installed from source in a non-default location.

In fact, for each of the 4 folders, I think there are 3 of them that prefer to have v0.12.2 and one that prefers to have v0.10.x.  Since that was the case, I installed each of the recommended versions separately in their respective folders.

What's strange is that if you download the version of node that is recommended, then it doesn't have the same corresponding version of npm that is recommended -- that is to say if you download the recommended node version off of the nodejs main site, the corresponding npm executable's version that is recommended from the install scripts does not match the version of the one installed with the matched version of node.

The previous two paragraphs (and this one) are more of an aside, and only loosely related to the error (although maybe they are more intimately related to the error than I am aware).

Thanks in advance!


29
General Discussion / Re: Is it possible for bitshares to become a sidechain of bitcoin?
« on: February 02, 2016, 10:15:21 pm »
Quote from: xeroc on February 02, 2016, 10:03:05 pm
Quote from: complexring on February 02, 2016, 09:55:57 pm
A potential solution to allow is to somehow have multisignature wallets associated to the balances that are held in collateral. If we can figure out a viable way of 'swapping' the associated private keys as different committee members are voted in and out, then there's no reason why we couldn't use something like that in order to achieve a pseudo-sidechain with BTC or any other alt.
That we can do today with a .. say 5 of 13 multisig account

Precisely.  Can't go much past 15 for N.  But anything like M of N with  3 <= M <= 8 and 15 >= N >= M should work.

Quote from: bytemaster on February 02, 2016, 10:10:12 pm
It is possible to do the following:

1. Have all of the witnesses monitor the BTC network for transfers to a designated multi-sig address which is defined by the BTS consensus to be the top 15 witness signatures (max MSIG allowed by BTC).   All of these UNSPENT OUTPUTS get included as part of BTS consensus state.

2. Every time a BTC transaction gets 6 confirmations, the blockchain transfers SIDE-BTC asset to a balance controlled by the first input address (assuming the address is a simple 1 sig input).

3. Allow this SIDE-BTC asset to be converted back to BTC with an operation that makes a request.  For witnesses to produce a block they must also sign off on the MSIG transfer authorizing BTC to be sent to the proper address.

This is something that could probably be implemented in about a month of dev time on the back end.

In theory the witnesses could collude to steal all deposited BTC funds.


Yes.  This is true, that in theory the witnesses could collude.  But, that's the risk some people may be willing to make because if they do collude, that drives the price of BTS down (since it would no longer be trusted) and then said witnesses wouldn't have an incentive to collude (unless they've sold off their BTS holdings).

30
General Discussion / Re: Is it possible for bitshares to become a sidechain of bitcoin?
« on: February 02, 2016, 09:55:57 pm »
A potential solution to allow is to somehow have multisignature wallets associated to the balances that are held in collateral. If we can figure out a viable way of 'swapping' the associated private keys as different witnesses are voted in and out, then there's no reason why we couldn't use something like that in order to achieve a pseudo-sidechain with BTC or any other alt.

edit: changed committee members to witnesses, as that is the proper terminology for this idea.

Pages: 1 [2] 3 4 5

Page created in 0.024 seconds with 23 queries.