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.


Topics - fluxer555

Pages: 1 [2] 3 4
16
General Discussion / Nubits and the Bter hack
« on: February 23, 2015, 06:00:08 am »
Nubits custodians must have gotten hit pretty hard by the Bter hack, yes? Is there any info on this?

17
General Discussion / Tether -- USD on the blockchain backed by bank account
« on: February 18, 2015, 05:50:10 am »
Friend or Foe?
What real advantages does BitUSD have over Tether?
What real advantages does Tether have over BitUSD?
How can we work together?
Where will we compete?

18
General Discussion / Deflating BTS through IPOs and sharedrops
« on: February 16, 2015, 05:35:01 am »
In the past I have proposed a deflationary development model in response to the the introduction of inflation on the BTS chain. I have since realized that this model is flawed since it does not actually give the developer fungible funds for their development. (I'll elaborate if anybody wants me to, however I'm going to refrain in sake of brevity).

I have another idea, which is also deflationary to BTS, but adds an interesting twist. It can be done in both IPO and sharedrop forms, or a combination.

The idea can be most easily described by defining different distributions for the new AwesomeCoin:

Scenario 0 -- Standard Proof of Burn (included for completeness)
100% to BTS burners who burn with the memo "AWESOMECOIN"

Scenario 1 -- Sharedrop
50% to BTS holders
50% to BTS burners who burn with the memo "AWESOMECOIN"

Scenario 2 -- Fundraiser
50% to donators of BTS
50% to BTS burners who burn with the memo "AWESOMECOIN"

Scenario 3 -- Fundraiser, hardstyle
45% or 55% to donators of BTS
45% or 55% to BTS burners who burn with the memo "AWESOMECOIN"
Whichever group is larger gets the larger percentage

Scenario 4 -- Sharedrop / Fundraiser combo
20% to BTS holders
40% to BTS donators
40% to BTS burners who burn with the memo "AWESOMECOIN"

Scenario 5 -- Sharedrop / Fundraiser combo, hardstyle
20% to BTS holders
35% or 45% to donators of BTS
35% or 45% to BTS burners who burn with the memo "AWESOMECOIN"
Whichever group is larger gets the larger percentage

"This is madness! Why on earth would anyone want to do this?"

For one, there currently exists a problem that the sharedrop pump/dump cycle creates a predictable trading environment which can be abused by shorters / BitUSD holders. By having part of the sharedrop include deflation of the currency, this can help soften or eliminate the 'dump' part of the cycle.

Additionally, having a dual drop system creates incentive for each side to be equal, which constantly drives the lesser side upward. As anyone who participated in the AngelShares drive knows, this had an adverse effect on the PTS price because it became fixed to the equivalent conversion of the daily BTC donations. With this, however, there is never any sell pressure on BTS or anything else, but you get the same affect of this pushing both sides up.

I can already hear you: "Why burn, if they could have just donated that to the fundraiser too?"
I'm not going to pretend to know, but it would be an interesting experiment to see if the total donated to the development fund would actually be driven higher due to the competition with the burned fund.

Of course, another added benefit from this is that the BTS supply deflates. This could be a consideration if the project is synergetic with BTS, and can be considered a kind of risk mitigation for the project if it is not successful.

Thoughts and comments appreciated.

19
General Discussion / Trust-minimized centralized exchange through multisig
« on: February 15, 2015, 06:00:49 am »
This is how I'm thinking of it:

1. When depositing currency A to the exchange, you transfer to a 2-of-3 multisig address. You own two keys, and the exchange owns another key.

2. When placing a trade for currency B, the exchange initiates a transaction to transfer the trade amount of currency A to a 1-of-2 multisig 'personal hot wallet', which you have to sign with one of your keys. You and the exchange each have a key for this 1-of-2 'personal hot wallet'. The exchange can transfer funds to the current owner(s) of currency B, and you can transfer the funds back if you need to cancel the trade.

3. When the trade executes, the exchange sends your new currency B to another 2-of-3 multisig address of that currency, which is the same as currency A's (you own two keys, they own one key.)

4. Whenever you want to 'withdraw' any currency, you can transfer the funds to a different wallet using both your keys. (I put 'withdraw' in quotes, because the money is barely 'deposited'; you own the funds and the exchange cannot steal or transfer them without your consent.)

Advantages:
- Exchange only has control of funds in the order book; you don't have to trust them with 100% of the funds you want to trade with
- Damage done by exchange getting hacked would be minimal; hackers would seek other targets for bigger rewards.
- The centralized service just acts as an escrow facilitator of transactions, and all transactions are voluntarily signed

Disadvantages:
- Speed of trading is limited by the block-confirm times of the currency
- This cannot work with Fiat or any non-cryptocurrency
- Having to confirm and sign all trade transactions manually could be annoying/tedious.

Some ways to combat these disadvantages are to, of course, use bitshares or bitassets as at least one side of the currency, as we have 10 second block confirms. If there is a fiat on-ramp for their corresponding MPAs, users could use this instead of centralized IOU fiat. Finally, instead of signing/confirming every transaction manually, an opensource exchange client could be built that handles automatically verifying the transactions.

I realize this may have limited utility since we can do a lot of this kind of trading right inside the client we already have, but I'm thinking that cross-crypto trading without IOUs or MPAs of those cryptos would be killer.

Thoughts?

20
I noticed this strange transaction just now:




In addition to it being strange that I did not initiate this transaction, I have never owned any TOURCOIN, so it is strange that it is possible for me to send any. Here is the transaction details page:



And here is a the page from bitsharesblocks, which includes strange data as well:
https://bitsharesblocks.com/blocks/block?id=1772398

What's going on here?

23
General Discussion / Hyperledger-Bitshares
« on: February 01, 2015, 02:20:54 pm »
I'm creating this thread to give bitsapphire a chance to explain the significance of integrating Bitshares with Hyperledger, and for us to discuss this with him and each other.

http://hyperledger.com/
https://github.com/bitsapphire/Hyperledger_cpp

24
General Discussion / Let's make sure faddat has good intentions
« on: January 24, 2015, 08:37:10 pm »
I'm making this post because my internal red flags are going off concerning the actions of faddat. I don't want to assume faddat is guilty of anything, nor do I want to cause any irrational hostility, but I just want to bring up some things that concern me. Faddat, please know that these are the same precautions that we should have with all and every contributor in your position. I'll try to be concise.

Faddat has two things he is planning to do: create a hardware wallet, and redo our forum.

In other words, he wants us to trust him with our private keys and our community.

Considering how new faddat is, I would like us all to do our due diligence with everything faddat produces, and I would like faddat to be transparent with all his code / hardware specifications / operations.

25
General Discussion / Does creating BitUSD = synthetic inflation?
« on: January 22, 2015, 05:51:59 pm »
If BitUSD becomes widely accepted as an alternative to paying in USD (99%+ of population accepts BitUSD), does this have the same economic consequences as increasing the USD supply? If so, then that means creating more BitUSD should have a direct effect on the value of USD. What does this mean for the peg?

I understand this is probably not going to be a problem for a long time, but I'm just curious as to what people think.

26
Technical Support / 0.5.1 Not building on OSX (10.8.5)
« on: January 22, 2015, 04:31:21 am »
I'm getting this error:

Code: [Select]
/Users/jules/bitshares/libraries/db/include/bts/db/fast_level_map.hpp:117:16: error:
      no viable conversion from 'const_iterator' (aka
      '__hash_map_const_iterator<typename __table::const_iterator>') to
      'decltype(this->_cache.find(key))' (aka '__hash_map_iterator<typename
      __table::iterator>')
        return _cache.find( key );
               ^~~~~~~~~~~~~~~~~~
/Users/jules/bitshares/libraries/blockchain/chain_database.cpp:3853:56: note:
      in instantiation of member function
      'bts::db::fast_level_map<fc::signed_int,
      bts::blockchain::account_record>::unordered_find' requested here
           const auto iter = my->_account_id_to_record.unordered_find( id );
                                                       ^
/usr/bin/../lib/c++/v1/unordered_map:546:24: note: candidate constructor (the
      implicit copy constructor) not viable: no known conversion from
      'const_iterator' (aka '__hash_map_const_iterator<typename
      __table::const_iterator>') to 'const
      std::__1::__hash_map_iterator<std::__1::__hash_iterator<std::__1::__hash_node<std::__1::pair<fc::signed_int,
      bts::blockchain::account_record>, void *> *> > &' for 1st argument
class _LIBCPP_TYPE_VIS __hash_map_iterator
                       ^
/usr/bin/../lib/c++/v1/unordered_map:546:24: note: candidate constructor (the
      implicit move constructor) not viable: no known conversion from
      'const_iterator' (aka '__hash_map_const_iterator<typename
      __table::const_iterator>') to
      'std::__1::__hash_map_iterator<std::__1::__hash_iterator<std::__1::__hash_node<std::__1::pair<fc::signed_int,
      bts::blockchain::account_record>, void *> *> > &&' for 1st argument
class _LIBCPP_TYPE_VIS __hash_map_iterator
                       ^
/usr/bin/../lib/c++/v1/unordered_map:570:5: note: candidate constructor not
      viable: no known conversion from 'const_iterator' (aka
      '__hash_map_const_iterator<typename __table::const_iterator>') to
      'std::__1::__hash_iterator<std::__1::__hash_node<std::__1::pair<fc::signed_int,
      bts::blockchain::account_record>, void *> *>' for 1st argument
    __hash_map_iterator(_HashIterator __i) _NOEXCEPT : __i_(__i) {}
    ^
In file included from /Users/jules/bitshares/libraries/blockchain/chain_database.cpp:2:
In file included from /Users/jules/bitshares/libraries/blockchain/include/bts/blockchain/chain_database_impl.hpp:5:
/Users/jules/bitshares/libraries/db/include/bts/db/fast_level_map.hpp:117:16: error:
      no viable conversion from 'const_iterator' (aka
      '__hash_map_const_iterator<typename __table::const_iterator>') to
      'decltype(this->_cache.find(key))' (aka '__hash_map_iterator<typename
      __table::iterator>')
        return _cache.find( key );
               ^~~~~~~~~~~~~~~~~~
/Users/jules/bitshares/libraries/blockchain/chain_database.cpp:3860:54: note:
      in instantiation of member function
      'bts::db::fast_level_map<std::__1::basic_string<char>,
      fc::signed_int>::unordered_find' requested here
           const auto iter = my->_account_name_to_id.unordered_find( name );
                                                     ^
/usr/bin/../lib/c++/v1/unordered_map:546:24: note: candidate constructor (the
      implicit copy constructor) not viable: no known conversion from
      'const_iterator' (aka '__hash_map_const_iterator<typename
      __table::const_iterator>') to 'const
      std::__1::__hash_map_iterator<std::__1::__hash_iterator<std::__1::__hash_node<std::__1::pair<std::__1::basic_string<char>,
      fc::signed_int>, void *> *> > &' for 1st argument
class _LIBCPP_TYPE_VIS __hash_map_iterator
                       ^
/usr/bin/../lib/c++/v1/unordered_map:546:24: note: candidate constructor (the
      implicit move constructor) not viable: no known conversion from
      'const_iterator' (aka '__hash_map_const_iterator<typename
      __table::const_iterator>') to
      'std::__1::__hash_map_iterator<std::__1::__hash_iterator<std::__1::__hash_node<std::__1::pair<std::__1::basic_string<char>,
      fc::signed_int>, void *> *> > &&' for 1st argument
class _LIBCPP_TYPE_VIS __hash_map_iterator
                       ^
/usr/bin/../lib/c++/v1/unordered_map:570:5: note: candidate constructor not
      viable: no known conversion from 'const_iterator' (aka
      '__hash_map_const_iterator<typename __table::const_iterator>') to
      'std::__1::__hash_iterator<std::__1::__hash_node<std::__1::pair<std::__1::basic_string<char>,
      fc::signed_int>, void *> *>' for 1st argument
    __hash_map_iterator(_HashIterator __i) _NOEXCEPT : __i_(__i) {}
    ^
In file included from /Users/jules/bitshares/libraries/blockchain/chain_database.cpp:2:
In file included from /Users/jules/bitshares/libraries/blockchain/include/bts/blockchain/chain_database_impl.hpp:5:
/Users/jules/bitshares/libraries/db/include/bts/db/fast_level_map.hpp:117:16: error:
      no viable conversion from 'const_iterator' (aka
      '__hash_map_const_iterator<typename __table::const_iterator>') to
      'decltype(this->_cache.find(key))' (aka '__hash_map_iterator<typename
      __table::iterator>')
        return _cache.find( key );
               ^~~~~~~~~~~~~~~~~~
/Users/jules/bitshares/libraries/blockchain/chain_database.cpp:3867:57: note:
      in instantiation of member function
      'bts::db::fast_level_map<bts::blockchain::address,
      fc::signed_int>::unordered_find' requested here
           const auto iter = my->_account_address_to_id.unordered_find( addr );
                                                        ^
/usr/bin/../lib/c++/v1/unordered_map:546:24: note: candidate constructor (the
      implicit copy constructor) not viable: no known conversion from
      'const_iterator' (aka '__hash_map_const_iterator<typename
      __table::const_iterator>') to 'const
      std::__1::__hash_map_iterator<std::__1::__hash_iterator<std::__1::__hash_node<std::__1::pair<bts::blockchain::address,
      fc::signed_int>, void *> *> > &' for 1st argument
class _LIBCPP_TYPE_VIS __hash_map_iterator
                       ^
/usr/bin/../lib/c++/v1/unordered_map:546:24: note: candidate constructor (the
      implicit move constructor) not viable: no known conversion from
      'const_iterator' (aka '__hash_map_const_iterator<typename
      __table::const_iterator>') to
      'std::__1::__hash_map_iterator<std::__1::__hash_iterator<std::__1::__hash_node<std::__1::pair<bts::blockchain::address,
      fc::signed_int>, void *> *> > &&' for 1st argument
class _LIBCPP_TYPE_VIS __hash_map_iterator
                       ^
/usr/bin/../lib/c++/v1/unordered_map:570:5: note: candidate constructor not
      viable: no known conversion from 'const_iterator' (aka
      '__hash_map_const_iterator<typename __table::const_iterator>') to
      'std::__1::__hash_iterator<std::__1::__hash_node<std::__1::pair<bts::blockchain::address,
      fc::signed_int>, void *> *>' for 1st argument
    __hash_map_iterator(_HashIterator __i) _NOEXCEPT : __i_(__i) {}
    ^
In file included from /Users/jules/bitshares/libraries/blockchain/chain_database.cpp:2:
In file included from /Users/jules/bitshares/libraries/blockchain/include/bts/blockchain/chain_database_impl.hpp:5:
/Users/jules/bitshares/libraries/db/include/bts/db/fast_level_map.hpp:117:16: error:
      no viable conversion from 'const_iterator' (aka
      '__hash_map_const_iterator<typename __table::const_iterator>') to
      'decltype(this->_cache.find(key))' (aka '__hash_map_iterator<typename
      __table::iterator>')
        return _cache.find( key );
               ^~~~~~~~~~~~~~~~~~
/Users/jules/bitshares/libraries/blockchain/chain_database.cpp:3919:54: note:
      in instantiation of member function
      'bts::db::fast_level_map<fc::signed_int,
      bts::blockchain::asset_record>::unordered_find' requested here
           const auto iter = my->_asset_id_to_record.unordered_find( id );
                                                     ^
/usr/bin/../lib/c++/v1/unordered_map:546:24: note: candidate constructor (the
      implicit copy constructor) not viable: no known conversion from
      'const_iterator' (aka '__hash_map_const_iterator<typename
      __table::const_iterator>') to 'const
      std::__1::__hash_map_iterator<std::__1::__hash_iterator<std::__1::__hash_node<std::__1::pair<fc::signed_int,
      bts::blockchain::asset_record>, void *> *> > &' for 1st argument
class _LIBCPP_TYPE_VIS __hash_map_iterator
                       ^
/usr/bin/../lib/c++/v1/unordered_map:546:24: note: candidate constructor (the
      implicit move constructor) not viable: no known conversion from
      'const_iterator' (aka '__hash_map_const_iterator<typename
      __table::const_iterator>') to
      'std::__1::__hash_map_iterator<std::__1::__hash_iterator<std::__1::__hash_node<std::__1::pair<fc::signed_int,
      bts::blockchain::asset_record>, void *> *> > &&' for 1st argument
class _LIBCPP_TYPE_VIS __hash_map_iterator
                       ^
/usr/bin/../lib/c++/v1/unordered_map:570:5: note: candidate constructor not
      viable: no known conversion from 'const_iterator' (aka
      '__hash_map_const_iterator<typename __table::const_iterator>') to
      'std::__1::__hash_iterator<std::__1::__hash_node<std::__1::pair<fc::signed_int,
      bts::blockchain::asset_record>, void *> *>' for 1st argument
    __hash_map_iterator(_HashIterator __i) _NOEXCEPT : __i_(__i) {}
    ^
In file included from /Users/jules/bitshares/libraries/blockchain/chain_database.cpp:2:
In file included from /Users/jules/bitshares/libraries/blockchain/include/bts/blockchain/chain_database_impl.hpp:5:
/Users/jules/bitshares/libraries/db/include/bts/db/fast_level_map.hpp:117:16: error:
      no viable conversion from 'const_iterator' (aka
      '__hash_map_const_iterator<typename __table::const_iterator>') to
      'decltype(this->_cache.find(key))' (aka '__hash_map_iterator<typename
      __table::iterator>')
        return _cache.find( key );
               ^~~~~~~~~~~~~~~~~~
/Users/jules/bitshares/libraries/blockchain/chain_database.cpp:3958:50: note:
      in instantiation of member function
      'bts::db::fast_level_map<bts::blockchain::address,
      bts::blockchain::balance_record>::unordered_find' requested here
           auto iter = my->_balance_id_to_record.unordered_find( id );
                                                 ^
/usr/bin/../lib/c++/v1/unordered_map:546:24: note: candidate constructor (the
      implicit copy constructor) not viable: no known conversion from
      'const_iterator' (aka '__hash_map_const_iterator<typename
      __table::const_iterator>') to 'const
      std::__1::__hash_map_iterator<std::__1::__hash_iterator<std::__1::__hash_node<std::__1::pair<bts::blockchain::address,
      bts::blockchain::balance_record>, void *> *> > &' for 1st argument
class _LIBCPP_TYPE_VIS __hash_map_iterator
                       ^
/usr/bin/../lib/c++/v1/unordered_map:546:24: note: candidate constructor (the
      implicit move constructor) not viable: no known conversion from
      'const_iterator' (aka '__hash_map_const_iterator<typename
      __table::const_iterator>') to
      'std::__1::__hash_map_iterator<std::__1::__hash_iterator<std::__1::__hash_node<std::__1::pair<bts::blockchain::address,
      bts::blockchain::balance_record>, void *> *> > &&' for 1st argument
class _LIBCPP_TYPE_VIS __hash_map_iterator
                       ^
/usr/bin/../lib/c++/v1/unordered_map:570:5: note: candidate constructor not
      viable: no known conversion from 'const_iterator' (aka
      '__hash_map_const_iterator<typename __table::const_iterator>') to
      'std::__1::__hash_iterator<std::__1::__hash_node<std::__1::pair<bts::blockchain::address,
      bts::blockchain::balance_record>, void *> *>' for 1st argument
    __hash_map_iterator(_HashIterator __i) _NOEXCEPT : __i_(__i) {}
    ^
5 errors generated.
make[2]: *** [libraries/blockchain/CMakeFiles/bts_blockchain.dir/chain_database.cpp.o] Error 1
make[1]: *** [libraries/blockchain/CMakeFiles/bts_blockchain.dir/all] Error 2
make: *** [all] Error 2

I installed all dependencies. Can anyone decipher this error as to what went wrong?

27
There seems to be a persisting overlap of the buyorders and sellorders for BitUSD. Why aren't they executing?

The fork doesn't happen for another 300 blocks.

28
Stumbled on this:

http://raiblocks.net/
https://github.com/clemahieu/raiblocks/
https://github.com/clemahieu/raiblocks/wiki

Apparently, this team has come up with a new consensus algorithm which does not use mining, nor does it use any kind of PoS. Each 'account' has it's own blockchain, and each account's blockchain interacts with each other to create a 'block lattice'. They apparently boast double-spend protection, and fast confirmations, and a myriad of other benefits. I'd be interested in some of the bigger brains here critiquing their methods.

29
Stakeholder Proposals / More than 1 delegate: who is this?
« on: January 15, 2015, 09:03:17 pm »
I noticed this on bitsharesblocks.com:



Only a few people had updated to 0.5, and given the pattern/style of these delegate names, it is probably that the same person owns these.

Who owns:
my.watch.begins.nightswatch
hear.me.roar.lion
fire.and.blood.dragon

??

30
General Discussion / Forward thinking: Creating markets of combined IOUs
« on: January 10, 2015, 04:40:30 am »
If we have many different IOUs from different gateways, would there be any way to implement setting up trade pairs, where one side can be any number of IOUs representing the same underlying asset?

Imagine there being BitStampUSD, BterUSD, and Btc38USD. Within the UI there could be three checkboxes corresponding to each gateway (BitStamp, Bter, Btc38). When you check Bter, you see all bid/ask orders for BterUSD. When you check Bter and BitStamp, you see the combined bid/ask of Bter and BitStamp. When you select all three, you see the combined orderbooks of all three gateways for this asset.


When selecting only one gateway, you only make trades with that gateway's IOU. When selecting more than one, you make trades with all that are selected.

Benfits:
• Combined liquidity
• Tightens spreads
• Simplified UI and UX
• Easily 'shop around' for best rates, keeping gateways competitive

Pages: 1 [2] 3 4