Author Topic: The Chinese community is upset over BTC38's non-response  (Read 5512 times)

0 Members and 1 Guest are viewing this topic.

Offline cube

  • Hero Member
  • *****
  • Posts: 1404
  • Bit by bit, we will get there!
    • View Profile
  • BitShares: bitcube
From their earlier correspondence, it seems BTC38 realised some discrepancies in their calculation and promised to investigate and provide a formal announcement.  This announcement never come to past.

https://bitsharestalk.org/index.php?topic=13529.msg179230#msg179230

Surprisingly, the Chinese is not getting a response from BTC38 yet. They are asking - https://bitsharestalk.org/index.php?topic=13529.msg193626#msg193626

Anyone in contact with BTC38?

no luck from my end .
Resend the thing again to one of the staff .

I hope they will response positively to the Chinese's needs.  To totally shut them out like this...  this is not the way to treat their customers.
ID: bitcube
bitcube is a dedicated witness and committe member. Please vote for bitcube.

Offline btswildpig

  • Hero Member
  • *****
  • Posts: 1424
    • View Profile
From their earlier correspondence, it seems BTC38 realised some discrepancies in their calculation and promised to investigate and provide a formal announcement.  This announcement never come to past.

https://bitsharestalk.org/index.php?topic=13529.msg179230#msg179230

Surprisingly, the Chinese is not getting a response from BTC38 yet. They are asking - https://bitsharestalk.org/index.php?topic=13529.msg193626#msg193626

Anyone in contact with BTC38?

no luck from my end .
Resend the thing again to one of the staff .
这个是私人账号,表达的一切言论均不代表任何团队和任何人。This is my personal account , anything I said with this account will be my opinion alone and has nothing to do with any group.

Offline cube

  • Hero Member
  • *****
  • Posts: 1404
  • Bit by bit, we will get there!
    • View Profile
  • BitShares: bitcube
From their earlier correspondence, it seems BTC38 realised some discrepancies in their calculation and promised to investigate and provide a formal announcement.  This announcement never come to past.

https://bitsharestalk.org/index.php?topic=13529.msg179230#msg179230

Surprisingly, the Chinese is not getting a response from BTC38 yet. They are asking - https://bitsharestalk.org/index.php?topic=13529.msg193626#msg193626

Anyone in contact with BTC38?
ID: bitcube
bitcube is a dedicated witness and committe member. Please vote for bitcube.

julian1

  • Guest
Hi Arhag. I really appreciate the support and interest shown by everyone. I attempted to read up on the threshold signature method, but confess it looks complicated and beyond my current knowlege/ability to implement.

Although it offers a more limited form of decentralization, the delegated multi-sig approach would be feasible. It's worth noting that both ltc and doge support multi-sig, probably using the same Bitcoin core codebase, meaning they could be supported too.

That said, I don't think it's entirely trivial. For example, if each node has the ability to broadcast transactions to p2p, then they must be completely deterministic and identical in form. Also there would need to be Bitshares client-side support for multisig asset issuance/burning which I don't think exists yet. 

I'm also considering, that If were to commit and ended up receiving delegate funding, it would curtail the time available to me to research / develop other projects that I feel could be useful. For example if it's necessary to go write some light blockchain parsers rather than http/rpc, then perhaps we should try to go for a genuine atomic cross-chain approach.
« Last Edit: February 15, 2015, 09:39:25 pm by julian1 »

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
One thing that's kept me from developing the btcgateway/xchain.info further is that I don't want to be the counterparty responsible for holding people's Bitcoin and Litecoin etc. And that applies irrespective of the fact that I believe I have a good sys-admin background to properly lock down servers.

That is understandable. The reserve shouldn't be protected by just one person anyway. If the threshold signature scheme I proposed is too much work for now, we could always use multisig instead. The problem is that Bitcoin has very strict limits on multisig with both their validity and standardness rules. The best we could do currently is m-of-n where m*73 + n*34 <= 496. So, for example we would probably want to do 4-of-6 multisig for the BTC reserves. If we choose 6 trusted delegates to be part of this multisig and provide them with the tools to automatically manage gateway operations, then we could take that counterparty risk off of you and have you just focus on making the tools.

Quote
Gateway assets make this much easier. In fact, maybe we should just skip GATEBTC and go for a GATEBITUSD UIA on DevShares backed by BitUSD locked on the BitShares blockchain by the counterparty.

I could do this.

Would there be interest in delegate sponsorship for something like this? I'm currently paying rent on multiple servers, and have already sunk about two months of development labor into GATEBTC (Still trying to make up the overtime/leave on my day job). I'm prepared to open-source, and can dramatically streamline the user-experience in terms of eliminating the need to expose private-keys.

I would vote for a 100% delegate for you. I would expect to see both GATEBTC for BitShares and GATEBITUSD for DevShares. The user shouldn't need to access a web site to do any transfers; it should all be possible through the DAC networks (perhaps utilizing the memo field of the transaction and/or linking accounts/addresses in the different systems using signed statements added to the public JSON of the accounts). The counterparties managing the reserves on the various blockchains (as well as the manager/issuer of the UIAs) should use multisig (as discussed above). And the easy-to-use tools the counterparties need to implement these gateways should be open-source.

Bump. Would love to hear what you think about this, julian1. Now more than ever we need GATEBTC. Even using 4-of-6 multisig where the 6 keys are from selected from our top 101 delegates is far more secure than trusting centralized exchanges with our cryptocurrency; they seem to keep getting hacked.

Offline onceuponatime


I could do this.

Would there be interest in delegate sponsorship for something like this? I'm currently paying rent on multiple servers, and have already sunk about two months of development labor into GATEBTC (Still trying to make up the overtime/leave on my day job). I'm prepared to open-source, and can dramatically streamline the user-experience in terms of eliminating the need to expose private-keys.

Why don't you ask Xeldal for some funds so you can get started right away as you write your proposal and wait for your delegate to be voted in. You can quote to him the support you have here.

*****************************************************************************
https://bitsharestalk.org/index.php?topic=13500.0
Delegate : fund.bitsharesbreakout

http://bitsharesblocks.com/delegates/delegate?name=fund.bitsharesbreakout

Site : http://bitsharesbreakout.com

Objective : To fund critical projects on an as needed basis without waiting for delegate funds to accrue.

Offline cube

  • Hero Member
  • *****
  • Posts: 1404
  • Bit by bit, we will get there!
    • View Profile
  • BitShares: bitcube

I would vote for a 100% delegate for you. I would expect to see both GATEBTC for BitShares and GATEBITUSD for DevShares. The user shouldn't need to access a web site to do any transfers; it should all be possible through the DAC networks (perhaps utilizing the memo field of the transaction and/or linking accounts/addresses in the different systems using signed statements added to the public JSON of the accounts). The counterparties managing the reserves on the various blockchains (as well as the manager/issuer of the UIAs) should use multisig (as discussed above). And the easy-to-use tools the counterparties need to implement these gateways should be open-source.

This is a good demand for this. Go for it!
ID: bitcube
bitcube is a dedicated witness and committe member. Please vote for bitcube.

Offline vegolino

  • Sr. Member
  • ****
  • Posts: 450
  • Reality is Information
    • View Profile

Quote
Gateway assets make this much easier. In fact, maybe we should just skip GATEBTC and go for a GATEBITUSD UIA on DevShares backed by BitUSD locked on the BitShares blockchain by the counterparty.

I could do this.

Would there be interest in delegate sponsorship for something like this? I'm currently paying rent on multiple servers, and have already sunk about two months of development labor into GATEBTC (Still trying to make up the overtime/leave on my day job). I'm prepared to open-source, and can dramatically streamline the user-experience in terms of eliminating the need to expose private-keys.

would vote for you as 100% delegate also!
  +5%
Definitely would vote for you as 100% delegate as well  :)

Offline cass

  • Hero Member
  • *****
  • Posts: 4311
  • /(┬.┬)\
    • View Profile

Quote
Gateway assets make this much easier. In fact, maybe we should just skip GATEBTC and go for a GATEBITUSD UIA on DevShares backed by BitUSD locked on the BitShares blockchain by the counterparty.

I could do this.

Would there be interest in delegate sponsorship for something like this? I'm currently paying rent on multiple servers, and have already sunk about two months of development labor into GATEBTC (Still trying to make up the overtime/leave on my day job). I'm prepared to open-source, and can dramatically streamline the user-experience in terms of eliminating the need to expose private-keys.

would vote for you as 100% delegate also!
█║▌║║█  - - -  The quieter you become, the more you are able to hear  - - -  █║▌║║█

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
One thing that's kept me from developing the btcgateway/xchain.info further is that I don't want to be the counterparty responsible for holding people's Bitcoin and Litecoin etc. And that applies irrespective of the fact that I believe I have a good sys-admin background to properly lock down servers.

That is understandable. The reserve shouldn't be protected by just one person anyway. If the threshold signature scheme I proposed is too much work for now, we could always use multisig instead. The problem is that Bitcoin has very strict limits on multisig with both their validity and standardness rules. The best we could do currently is m-of-n where m*73 + n*34 <= 496. So, for example we would probably want to do 4-of-6 multisig for the BTC reserves. If we choose 6 trusted delegates to be part of this multisig and provide them with the tools to automatically manage gateway operations, then we could take that counterparty risk off of you and have you just focus on making the tools.

Quote
Gateway assets make this much easier. In fact, maybe we should just skip GATEBTC and go for a GATEBITUSD UIA on DevShares backed by BitUSD locked on the BitShares blockchain by the counterparty.

I could do this.

Would there be interest in delegate sponsorship for something like this? I'm currently paying rent on multiple servers, and have already sunk about two months of development labor into GATEBTC (Still trying to make up the overtime/leave on my day job). I'm prepared to open-source, and can dramatically streamline the user-experience in terms of eliminating the need to expose private-keys.

I would vote for a 100% delegate for you. I would expect to see both GATEBTC for BitShares and GATEBITUSD for DevShares. The user shouldn't need to access a web site to do any transfers; it should all be possible through the DAC networks (perhaps utilizing the memo field of the transaction and/or linking accounts/addresses in the different systems using signed statements added to the public JSON of the accounts). The counterparties managing the reserves on the various blockchains (as well as the manager/issuer of the UIAs) should use multisig (as discussed above). And the easy-to-use tools the counterparties need to implement these gateways should be open-source.

julian1

  • Guest
Its a chicken and egg problem with all mayoe exchanges. .. we need them to trade bts for price discorvery yet we dont like them to store alot of bts for security reasons

We don't need centralized exchanges for price discovery. We could use bitcoin gateways instead. Then price discovery (and purchasing BTS directly with "bitcoins") is possible on our decentralized exchange. No counterparty risk for the BTS being traded (just the "bitcoins") and more importantly voting rights are kept in the hands of the stake owners and not the exchanges.

This is how I hope we do price discovery for DVS. We just need julian1 and/or monsterer to set up GATEBTC for DevShares.

Also, I would love it if we could have a BitShares Standard Gateway for ECDSA coins to further reduce the counterparty risk.

It's an interesting idea. One thing that's kept me from developing the btcgateway/xchain.info further is that I don't want to be the counterparty responsible for holding people's Bitcoin and Litecoin etc. And that applies irrespective of the fact that I believe I have a good sys-admin background to properly lock down servers.

The null-street marketers keep saying we need to tap Bitcoin evangelism for our common interest  with a shared-wallet. Another viable approach would be to have multi-sig/shamir's secret backed redeemable BTC/LTC 'upgrade' assets on our own fast blockchain. Bitshares can then be pitched as a Bitcoin 'side-chain' for the marketing network-effect.

Quote
Gateway assets make this much easier. In fact, maybe we should just skip GATEBTC and go for a GATEBITUSD UIA on DevShares backed by BitUSD locked on the BitShares blockchain by the counterparty.

I could do this.

Would there be interest in delegate sponsorship for something like this? I'm currently paying rent on multiple servers, and have already sunk about two months of development labor into GATEBTC (Still trying to make up the overtime/leave on my day job). I'm prepared to open-source, and can dramatically streamline the user-experience in terms of eliminating the need to expose private-keys.

Offline Troglodactyl

  • Hero Member
  • *****
  • Posts: 960
    • View Profile
No, its more like "How the 'merger' killed bitshares"
Satoshi was against incorporating "BitDNS" feature (and other "generalization" features) into Bitcoin,
saying:
Quote from: satoshi
Piling every proof-of-work quorum system in the world into one dataset doesn't scale.
I hope above helps.
Which is why we use DPOS, to eliminate POW and enable scaling by limiting required redundancy to the point we consider it actually useful for resiliency and security.

Offline dna_gym

  • Jr. Member
  • **
  • Posts: 20
    • View Profile
No, its more like "How the 'merger' killed bitshares"
Satoshi was against incorporating "BitDNS" feature (and other "generalization" features) into Bitcoin,
saying:
Quote from: satoshi
Piling every proof-of-work quorum system in the world into one dataset doesn't scale.
I hope above helps.

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
We don't even need to have active IOU to bitshares markets for price discovery. Delegate price feeds can just measure the peg of bitassets instead, and then multiply the internal market rate with the peg deviation to produce the feed for minimum short price, or let bitassets be shorted freely if there is no peg deviation (say within 1% error margin).

How would you know what is the peg deviation of DevUSD from real USD if it is not trading against any asset that derives its value (in USD) from some chain of trading pairs leading to USD? We would only know whether the peg is actually working or not if DevUSD started trading against something like BTC or BTS or BitUSD at the expected price. I guess DevUSD could trade against BTC in centralized exchanges, but then wouldn't they just integrate DVS as well? I would prefer if we avoid using centralized exchanges for any DevShares assets because of how frequently we expect to hard fork the blockchain.

I guess one other way we could do it without gateways is through atomic cross-chain trading. If people are exchanging DevUSD for BitUSD 1:1 then we know the peg is good and the price feed doesn't need adjustments. But that information isn't very transparent or easy for the delegates to aggregate. Gateway assets make this much easier. In fact, maybe we should just skip GATEBTC and go for a GATEBITUSD UIA on DevShares backed by BitUSD locked on the BitShares blockchain by the counterparty.

Offline Ander

  • Hero Member
  • *****
  • Posts: 3506
    • View Profile
  • BitShares: Ander
and that was how the little BitShares killed the centralized exchange

the end

No, its more like "How the 'merger' killed bitshares"
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads