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 - arhag

Pages: 1 ... 12 13 14 15 16 17 18 [19] 20 21 22 23 24 25 26 ... 81
271
@arhag: Some thoughts
 - I decided to not 'construct' the transaction on the online computer. This way a hacker would need to compromise the offline computer to modify the unsigned transaction
 - I chose to not support TITAN but let the user issue "wallet_create_address <account>" so that the end user has a chance to verify the signed JSON transaction prior to sending it to the network

I'm not worried about security issues with the approach I proposed. Let's assume that the hot client is completely compromised.

Let's say the user somehow got the address for which the private key is stored in the hot client (they would likely need to write it down somewhere since they couldn't trust the output of their hot client), verified that it was typed in correctly in the offline tool, signed the transaction sending X BTS to it, and then moved the signed transaction back to an online computer and broadcast it. If the hot client is compromised, the hacker will just redirect the funds to himself as soon as they arrive at the hot client's address. So typing out the address in the offline tool (or alternatively verifying the address you are sending funds to in the offline tool) doesn't provide you with any extra security if it is a hot address.

What is important, however, is to know how much money you are withdrawing from the cold storage address. This is why I had the offline_sign.py tool tell the user:
Code: [Select]
A total of the following assets will be moved out of cold storage:
    20.00000 BTS
If a hacker modified the output of need-to-sign-2.txt to instead send 20,000 BTS to him, the user would notice the discrepancy in the output of the offline_sign.py tool and not continue with signing. Everything else (at least for offline signing of regular transfers) is IMHO superfluous with no real security benefit and in fact is worse in that it complicates the UX for the user.

272
Nice job.

One thing I would suggest, however, is that the online part allow you to specify the recipient and the amount and type of assets to transfer, and of course save that necessary information in the text file. That way all the offline part needs to do is ask for the private key and sign the transaction.

And then instead of providing a deposit address I can simply provide a BTS account name.

So the online main.py (renamed offline_transactions.py) could take arguments as follows:
./offline_transactions.py --output <output_filename> --transfer "<amount_to_transfer> <asset_symbol> <from_cold_storage_address> <recipient> [memo_message] [strategy]"
where the transfer argument (of which there can be multiple specified) specifies multiple arguments for the transfer in a similar way as the wallet_transfer command.

So for example:
Code: [Select]
$ ./offline_transactions.py --output need-to-sign-1.txt --transfer '10 USD BTS4CNbXqeEym7JopKYvL16qVKUe9kRMMC8x xeroc "Withdrawing funds from cold storage" vote_all'
1 transaction written to file 'need-to-sign-1.txt' for offline signing.

Or later when the new contact system is enabled:

Code: [Select]
$ ./offline_transactions.py --output need-to-sign-2.txt --transfer '19.5 BTS label:cold-storage xeroc'
1 transaction written to file 'need-to-sign-2.txt' for offline signing.
This would grab the cold storage address stored as a contact under the label cold-storage within the wallet that the script is configured to connect to.

Then on the offline computer (offline main.py renamed offline_sign.py):
Code: [Select]
$ ./offline_sign.py --input need-to-sign-2.txt --output signed-2.txt
1 transaction needs to be signed.
1 private key is necessary to sign transactions.
A total of the following assets will be moved out of cold storage:
    20.00000 BTS

Require private key for address BTS4CNbXqeEym7JopKYvL16qVKUe9kRMMC8x. How would you like to provide the private key?
1) Type in WIF private key
2) Use QR scanner
3) Derive from brain key
Select option: 1
Enter private key: 5**************************************************
All necessary private keys collected.

1 transaction successfully signed and output written to file 'signed-1.txt'
To broadcast transaction run ./offline_transactions.py --broadcast 'signed-1.txt' on online computer

Then back on the online computer:
Code: [Select]
$ ./offline_transactions.py --broadcast 'signed-1.txt'
Found 1 valid signed transaction. Latest expiration time of transactions is 2015-03-19T08:23:15 (2 hours in the future).
Would you like to broadcast all transactions? [Y/n] Y
Broadcasting transactions... OK
Waiting for confirmation in blockchain... OK
All transactions successfully broadcast.
Or something like that.

273
Nice. Now I suggest offering a small bounty for someone (pc seems like the ideal candidate) to improve the blockchain_generate_snapshot command to work with any asset type as described here:
Finally, you need to generate the map in the first place. It would nice if there was blockchain_generate_snapshot command that worked for any asset rather than just BTS. I'd imagine that it shouldn't be too difficult to create such a command. It seems like one could just copy the chain_database::generate_snapshot function and make some tweaks to support any non-BTS asset (it wouldn't need to worry about delegate pay balances, vesting balances, short order balances, or collateral balances, but it should be careful to pay attention to both asks and bids to not miss any markets that are trading the asset). One thing to wonder about is what would happen to assets protected by multisig or stored in escrow? I guess worst case scenario you tell your UIA holders to not hold the UIA in any multisig or escrow at the time of the pre-announced snapshot. Although it would be better if wallet_asset_issue_to_addresses allowed for reconstructing multisig withdraw conditions (then the snapshot generation tool would be augmented to support recording multisig balances and escrows could be treated as a 2-of-3 multisig).

And then all that is left after that is to:
  • Create a new data directory (which I will refer to as $NEW_DATA_DIR) and copy the existing chain folder into it (or rather just the chain/raw_chain folder). Run the BitShares client with "bitshares_client --data-dir $NEW_DATA_DIR --rebuild-index --stop-before-block 2000001" and wait until it rebuilds the index up to block 2000000 (can I get confirmation from devs, particularly theoretical, that this will do what I think it will do). Then once at block 2000000 (verify with get_info), use the new blockchain_generate_snapshot command to generate the snapshot to an output file. After the snapshot output file is generated and copied to a safe place, the client can be closed and the new data directory can be deleted.
  • Go back to the wallet that has the issuer of your CFSAssets and create a new sharedrop asset (let's call it CFSGOLD.B).
  • Write a small script that reads the snapshot output file and generates the allocation map for the new sharedrop asset (with appropriate scaling of values), then breaks up this map into disjoint pieces that are each of a reasonable size so that the resulting transactions are not too large in size (it would be nice if devs could let us know what the optimal max for the number of unique keys in the each map should be), and for each of these disjoint maps m, it uses the RPC (connected to the wallet of the issuer of the CFSGOLD.B asset) to call wallet_asset_issue_to_addresses CFSGOLD.B m. Do dry runs that print out the sequence of disjoint maps and publish them for everyone to verify it is accurate.
  • And finally when you are ready to actually distribute the sharedrop asset, run the script for real on the snapshot output file produced from the first step. And make sure you have enough BTS in the issuer account to cover all the necessary transaction fees (at least 0.1 BTS * number of disjoint maps).

274
General Discussion / Re: how to change between TITAN &NON TITAN?
« on: March 18, 2015, 04:10:52 am »
OMG
public accounts do not receive memos and all payments are made to the active key
&blockchain_get_account_public_balance  can show the balance

Yup  :(

Although it seems wrong to me that public accounts do not receive memos. There is no reason this has to be the case (encrypted memos are doable with transfers to public accounts without requiring the public account to scan the blockchain). Can I get confirmation from devs on this?

275
General Discussion / Re: exchange is a big bomb!
« on: March 18, 2015, 03:57:51 am »
They claim to have 258 million bts total among all users.

Wow! That's over 10% of the supply. Is that typical? I wonder what percentage of BTC are on exchanges.

Imagine, that is 10% of BTS that could have been voting if it was trading on the DEX (and voting with collateral and market order BTS was supported).

If people are going to use BTS on outside exchanges it would at the very least be nice if it was BitBTS (a BitAsset that has 100% collateral requirements, no margin calls, and a fixed price of 1 BitBTS/BTS). BitBTS would allow people to self-short in order to split BTS into its voting rights (BTS held in collateral in the BitBTS short positions) and its value (BitBTS which can be used to claim the same quantity of real BTS in less than 30 days).


How can one see how many BTS are in an account on the blockchain?  I thought we couldnt do this because of titan.  How do we verify that btc38 has the claimed 258M bts?

If they're willing to vote once , then the vote record with large amount will be seen .

I'm sure a blockchain analysis could give us a pretty good estimate even without votes if we see which balances our deposit go to and withdrawals come from.

276
General Discussion / Re: exchange is a big bomb!
« on: March 18, 2015, 02:57:08 am »
There is also Metaexchange.info. As volume ramps up so will their depth.

It's great but it's not really an exchange, it's a bridge. Basically you can only place market orders. You can't place orders at particular prices into the order book.

Also, I think the market makers should all be competing with their bots on a neutral platform (the DEX). The bridge would still want to keep some floating funds to instantaneously find the best liquidity path from the source asset to the target asset (that is the convenient service the bridge provides to users IMO), but I think the serious market makers should be decoupled from any bridge and operating for profit by themselves on the neutral DEX. And traders wouldn't be using a bridge, they would place their own orders directly on the exchange.

277
General Discussion / Re: exchange is a big bomb!
« on: March 18, 2015, 02:09:55 am »
and BTC38 have do nothing to prove their balance is true.
so this is a very big bug!
exchange can control the price very easy, I will not surprise even BTS down to zero.

You know which exchange we actually can trust to be honest? The BitShares decentralized exchange.  :)

It may be too soon, but my hope is that we can have the vast majority of BTS trading volume happen on the BitShares DEX in the near future. We likely need secure lightweight/web wallets with exchange support before that can happen though. We also need a multisig protected BTC gateway UIA. @dannotestein, what will it take to get TRADE.BTC protected by multisig (on both BTC reserve side and TRADE.BTC UIA side) in a easy-to-deploy solution that can be utilized by some subset of the delegates? I think the money-making part should be left to the bridge service and that the gateway should be more of a public good for the BTS community (it should still be profitable to operate though) which means making this easy-to-deploy software solution open source and allowing a subset of the delegates operate it with low profit margins.

278
Although there's more steps, it achieves essentially the same function as a voluntary short cover in the current regime.

It seems exactly like the voluntary short cover in the existing system. This wasn't the problem.

Its also possible to have a converse mechanism to create supply if new borrowers wish to act more urgently. For example, the new borrower can self-create a loan and corresponding units of bitCurrency, as long as their interest rate satisfies some minimum condition that does not give them unfair interest rate advantage relative to the current market (not sure what such condition should be yet).

Well you told me to assume that the loans aren't callable in this discussion (which is essentially the same as going back to the BitAsset system with no expiration period). In such a case, this sort of self-shorting outside of the market isn't an issue. This was already discussed in fact in a thread bytemaster posted about a proposal to simplify the BitAsset system which has since been rejected. The problem with the proposal is that if you do want an expiration period, the self-shorting outside the market allows borrowers to get around the expiration restrictions. Those selling below the price feed expect to be matched within 30 days, but if a short can just roll over their shorts outside of the market, those BitAsset sell orders under the price feed may remain for an indefinite amount of time. A tweak to correct this is to disallow self-shorting outside the market if there are any BitAsset sell orders under or at the price feed (but with that restriction in place you might as well just use the current system and match your own short). To use your terminology, a borrower would not be allowed to self-create a loan if there is a withdrawal waiting in the queue.

- all participants can be guaranteed the feed price, subject to queuing

That isn't just a small detail though. I can "guarantee" any price for any asset as long as the time at which it will be settled is allowed to be unbounded. I will sell BTS at a price of $0.00001 to anyone who agrees to not be paid until 5,000 years later. It is pointless. If I put a buy or sell order stuck just above the price feed, there is a very good chance in the current system that my order will be matched in a reasonable amount of time (days if not hours). If I put a sell order stuck just below the price feed, there is a guarantee by the system that it will be matched within 30 days.

From that perspective, being able to trade away from price feed on the DEX is not a problem, it is a feature (it combines the external free market and the "bank" into a single combined market). Anyone who wants to restrict themselves to just the price feed can do so and have upper bounds on the time they will spend in the queue for BitAsset sell orders (just like they have an upper bound on the time a withdrawal stays in the queue in your system assuming you make loans callable after some finite time and you put the restriction on self-creating loans that I described above), and while they won't have any guarantees or upper bounds on time spent in the queue for BitAsset buy orders (just depositors might spend an indefinite amount of time in the queue in your system), it is usually safe to assume that buy orders at the feed price will be matched relatively quickly (days).

- when free market prices are at a premium, there is incentive to create new currency units instantly and sell them in the free market

How so? I already discussed that with my short example. For there to be a profit incentive, the borrower needs to be able to take the BTS collected by selling the premium BitAssets in the free market and deposit it into the bank to get the BitAsset needed to cover the loan. But there is no guarantee that deposit will be matched immediately. By the time the deposit is matched, the price feed may have moved significantly to the disadvantage to the borrower. In other words, this isn't risk-free arbitrage. And again, this is the same thing as the current system. The external market and the "bank" in your proposed system are just merged into one combined BTS:BitAsset market with mixed order types (which in fact makes actual risk-free arbitrage automatic and unnecessary for people to do, not including arbitrage with other external markets that happen to be trading the BitAssets and BTS of course).

- when free market prices are at a discount, there is incentive to buy currency units in the free market and instantly destroy them

Only if the borrower will realize profits by doing so. If the feed price when they borrowed is lower (in BTS/BitAsset) than the the current feed price, it may not necessarily be profitable to buy the discount BitAsset and cover (or self-cancel). It depends on how much the discount is and how much the feed price has changed since the loan was created (also interest rates would have to be factored in). But in a long bear market (like we have been experiencing), the borrowers would be at a loss and would not wish to realize that loss by buying even discount BitAssets and covering. This is why the expiration is a good thing for helping the peg, especially in bear markets, because it forces the borrowers to cover at the price feed after a reasonable amount of time (thus increasing liquidity and supporting the peg) despite the fact that it causes them to realize their losses which is why they wouldn't have covered had it not been for the expiration.

The arbitrage and market-making mechanisms are really key to whether this whole approach radically improves pegging and liquidity in the free markets, and I will try to give these more attention, but my current thinking is the proposal will at least improve current conditions.

I believe this proposal is nearly equivalent to the current BitAsset system with no expiration period, and will have similarly liquidity as we would if tweaked the current system to removed the expiration period (which I believe would be worse liquidity in bear markets, so that means worse liquidity than we have at the moment). I also believe that this proposal with instant withdrawals and loan callability is nearly equivalent to the current BitAsset system with an expiration period of 0 days (maybe some minor additional tweaks needed), and will have similar liquidity as we would if we tweaked the current system to set the expiration period to 0 days (which I believe would be even worse liquidity than today because any of the remaining short sellers that are still selling today would likely be scared off by a 0 day expiration period).

The difference to the current system is that rather than all loans sitting unnecessarily at the feed after 30 days, the proposed system would selectively call on the loans as required, ranking on interest (and collateral where low). This provides incentive for keener borrowers to improve their terms, and allows them the flexibility to carry the loan as long as they desire.

Right, as I mentioned before I like the idea of adjusting the order matching rules of expired cover orders to first pick the ones corresponding to shorts that offer the lowest interest rates. I also like the idea of allowing a short position owner to increase (but not decrease) the interest rate the short pays after getting matched (even if expired).

I believe those are the only changes necessary to the current system for it behave essentially the same way as the system you are proposing (now that you are willing to accept 30 day periods before loans become callable).

279
General Discussion / Re: Cryptohedge and the bter hack
« on: March 18, 2015, 12:20:22 am »
Does a mechanism currently exist for doing a sharedrop on UIA holders?

Nothing yet. At least not in the nice intuitive way where you just specify the amount and type of the dividend asset and the type of your UIA that you wish to distribute the dividend to  (also nothing where the dividend issuing transaction size is fixed, and thus the transaction fee to issue the dividend is fixed).

You could always run a script that takes a map between addresses and amounts and makes the transfers one-by-one to each of the addresses for the corresponding amount of the UIA.

Then there is wallet_asset_issue_to_addresses. But like the description says wallet_asset_issue_to_addresses doesn't "do any magic for you" it just helps do the work of the script I discussed in the previous sentence on your behalf.

Of course, there is the possibility that the transaction exceeds the maximum transaction size (if there are many addresses to pay), in which case you would have to break up the map into pieces and use wallet_asset_issue_to_addresses multiple times (and pay multiple transaction fees).

Finally, you need to generate the map in the first place. It would nice if there was blockchain_generate_snapshot command that worked for any asset rather than just BTS. I'd imagine that it shouldn't be too difficult to create such a command. It seems like one could just copy the chain_database::generate_snapshot function and make some tweaks to support any non-BTS asset (it wouldn't need to worry about delegate pay balances, vesting balances, short order balances, or collateral balances, but it should be careful to pay attention to both asks and bids to not miss any markets that are trading the asset). One thing to wonder about is what would happen to assets protected by multisig or stored in escrow? I guess worst case scenario you tell your UIA holders to not hold the UIA in any multisig or escrow at the time of the pre-announced snapshot. Although it would be better if wallet_asset_issue_to_addresses allowed for reconstructing multisig withdraw conditions (then the snapshot generation tool would be augmented to support recording multisig balances and escrows could be treated as a 2-of-3 multisig).


It would be the best way to handle this but I don't know how we can do it. If its not possible to do at the moment then our options are to either auction off the IOU's and distribute the proceeds when we re-enable trading, or to take a snapshot and then do the sharedrop to the snapshot addresses at a later date when sharedrop tools have been developed.

Actually, yeah, I think it makes the most sense to just announce a snapshot and then resume the markets at a new NAV of 0.7 so people can withdraw their portion of their funds as soon as possible. The sharedrop would happen later (when there is a better support for it) but presumably the BTC repayment on the IOUs would take a while anyway.

280
I would say you shouldn't really assume anything. Even in the closest milestone, an issue might be there just to signify "ok just look at this now and then decide where to move it".

Well, to reiterate what many other people on this forum have been saying for a while now: we really need a proper roadmap from the core devs. Maybe something like: features/fixes that are definitely planned (with some priority ranking), features/changes that are still being considered, and features/changes that are frequently requested by the community but have been rejected by the core devs for the foreseeable future (with a reason explaining why).

281
Here are some of my thoughts:

1) It allows anyone with access to the internet to participate in the global financial system regardless of what restrictions their local financial gatekeepers have set up.
These restrictions can be intentionally imposed by their government for whatever reason, or it may just be a byproduct of it not being profitable enough to set up traditional financial institutions there (I'm referring to the unbanked).

This can provide a lot of good to people (especially poor people). They don't have to deal with cash for their business that can easily be stolen. They will have access to same investment instruments that people in developed nations (I'm considering future financial innovations on the blockchains here like bond markets, loans, and companies that issue cryptostock on the blockchain) will have since the blockchain does not discriminate. Speaking of loans, even people in developed nations like the US will have more investment opportunities because of the blockchain. Non-accredited investors can provide micro-loans to people stimulating development that would have otherwise not occurred because it wouldn't be worth the traditional bank's time (of course they can also be scammed into losing their money, but I really dislike the nanny state that restricts the level of risk individuals are allowed to take with their own money in investments/gambling).

There are of course potentially negative aspects to this as well, which may interesting to touch on in the paper. For example, without an easy way to impose capital controls, it becomes difficult for a government to sanction another country. They could still restrict shipping of physical goods to and from that country (unless an intermediate proxy country is used), but it would be too difficult to restrict purchasing of services that can be entirely consumed digitally (creating media, software services, etc.). Now this may actually be seen as a positive depending on one's political philosophy and the particular instance of the sanction and whether one thinks it is justified or not, but for the paper I think it is still worth exploring what it means geopolitically when governments lose (or at least weaken) that stick from their tool bag which has helped them get what they want. And of course one could explore what blockchain technology means for money laundering, supporting criminal activity, and financing terrorism.

Anyway, moving back to the positives...

2) Transparent, fraud-free online voting is a huge deal IMO.

I suspect once you lower the barrier to entry (allow people to vote early and often from their smartphone) and give them confidence that their vote is actually counted then voter participation will go up. Also, if you can vote early and update your vote before a deadline, it allows you to vote how you really like rather than for the lesser of two evils and then change your vote in the last day to vote strategically. And since everyone can also follow this strategy, it means you get to see how everyone else would really like to vote. This means if you vote for some party or candidate that the media tells you has no chance but it turns out they actually have very large support and can win, you don't bother changing your vote. On the other hand, if the media is correct and that candidate only has less than 10% of the vote, you could then change your vote in the last day to pick the lesser of two evils that actually stands a chance of winning. I hope a voting system like this may stand a chance of breaking up the two-party system in US and actually providing real change to the government by allowing candidates that a larger percent of the population actually likes to be elected rather than one of the two serious contenders that they hate a little less than the other serious contender.

3) Smart contracts.

I agree that your points 3a and 3b in that post are very interesting to focus on. I find the idea of imposing restrictions on yourself through a public smart contract for the purpose of gaining benefits from other people very interesting. The smart contract is immutable and public (so you cannot change the conditions in the future in a way that is not supported by the contract), is enforced by the blockchain (so people have a guarantee that once the conditions of the contract are triggered, the stated outcomes will occur), and precisely (through code) defines the mechanisms through which these triggers can occur (typically this could not be done through software alone and would involve selecting arbitrators or oracles that feed in the data that triggers the contracts). For the enforcement of the contract by the blockchain to have any weight there would need to be something the user loses if they fail to meet the obligations of the contract. This can include cryptocurrency locked in the smart contract or other locked assets that can be automatically sold through an exchange or auction for cryptocurrency to pay off debts and pay for restitution, and/or simply recording how much money the user (who in this case would have to have a real-world identity established and linked to the blockchain account to prevent Sybil attacks) owes to others (to pay them restitution) on the immutable blockchain. In the third case, the user could enter smart contracts without having anything of value on hand other than their good reputation. If they already have a bad reputation because of previous bad marks from failure to meet the obligation of their previous contracts, no one would take the new smart contracts seriously (at least until they pay restitution to their victims of previous smart contracts to clear their bad marks). The beauty of these smart contracts is that each individual gets to choose the precise terms that they wish to impose on themselves, however they would of course be restricted to choosing terms that others will find acceptable to do business with them. The reason they bother imposing such limitation on themselves is to be able to do business with others, which they need to do if they wish to survive and thrive in society.

I also should be clear by what I mean by precisely defining the conditions of the contract. I am not talking about the part of the contract that the arbitrator uses to judge outcomes. That of course remains as vague and subjective as it is today. The part I am talking about are things like you must pay X amount every month otherwise you default on the loan, or the variable interest rate of your loan can only increase annually by at most some fixed amount. And all of this would be precisely defined through a programming language. Although it is a small part of the contract, I think getting as much as is possible of the contract done through precisely-defined code in the smart contracts helps. The challenging part is of course the subjective stuff that requires human judgement. Blockchains don't help with that problem (I'm not pretending like blockchains are some panacea). But smart contracts do add an interesting advantage to even this subjective component in that the creator of the contract can define the consensus conditions necessary for the group making these human judgement. The contract can define a set of human judges a priori and give each a weight. Then if the sum of the weights of judges from this set who agree on a particular decision (a decision restricted to some finite set of possible decisions defined in the smart contract) is greater than some threshold, the blockchain carries out the execution of that decision as defined in the smart contract.

My hope is that these systems can replace much (but I don't personally believe it can replace all) of the traditional justice system. Trying to use smart contracts to replace all of the traditional justice system starts to, IMO,  make the new system start looking more like just a technologically-sophisticated version of traditional state-based justice rather than "private law"). Let me expound on that.

One can still opt-in to punishment under certain circumstances as defined by the smart contract they enter. One might bother doing this because they carefully weigh the pros and cons of entering this smart contract versus not entering the contract and come to the conclusion that the self-restriction is in their net benefit due to the access it gives them to goods and services made available by other people in the society which they could otherwise not access if they refused to enter the contract. Now when I talk about punishment I am typically talking about things like forfeiting bonds that, for example, are paid, if necessary, by auctioning off property assets which the smart contract has a lien on. I am imagining some hypothetical future where you can have a property deed digital asset on the blockchain (which has value because some credible enforcer will respect the property rights of the owner who can prove ownership of the digital property deed through cryptographic signatures) and you can put it up as collateral for a mortgage-backed security smart contract, for example. Short of that, however, the public, immutable blockchain could just record what the person (who has an verified real life identity associated with the blockchain account they enter smart contracts with) still owes, or what their other punishment is, and there would be an expectation that the person satisfy that punishment / restitution to get back good standing in the community.

These punishments would be activated if you break certain rules. The rule specifications can be modified by a legislative group (whose members can change through a process described a priori in the smart contract) and the claim of whether one's specific actions actually broke the rules (and what the corresponding punishment is, constrained by the rule specifications) can be determined by a judicial group (whose members can change through a process described a priori in the smart contract). This all starts resembling our existing government system very quickly. But the constitution is made more precise and better enforced through code and in theory an infinite number of variations can be adopted. In practice, I believe societies will tend to adopt very similar smart contract frameworks (where the similarity becomes stronger the more we narrow the view to smaller geographically local societies) simply because they need a certain amount of compatibility between their smart contracts to be able to safely and securely trade, work, and live together, and also because if everyone's smart contract were widely different, there would be a huge cognitive burden in evaluating how compatible a counterparty's smart contract is to one's own smart contract when deciding whether to interact with them.

Then, the issue is what do you do if one has an incompatible smart contract they impose on themselves (or in fact they don't impose any limitations on themselves) but still wants to interact with you? What if despite your request to be left alone, they keep bothering you? What if they are malicious and attack you to steal your property or just hurt you for pleasure/revenge? This then requires enforcers of a given society to physically separate the people with very incompatible (compared to that of the society) smart contracts from the rest of the society. Essentially they would be partly be the police and partly be the border patrol and customs of a nation. In theory this can operate at any scale, but my guess is that in practice it will efficiently operate at the scale of typical nations/states today.

There is also the additional problem of negative consequences to a society even when the aggressors are physically separated. Examples include: cyberattacks (hacking computer systems), cyberbullying, intellectual property infringement (if the society recognizes intellectual property), certain types of publications (whether information, true or not, or visual/auditory depictions, real or simulated) that are found to be undesirable by the society, pollution, overuse of natural resources, global warming, etc. For some societies, these issues may just be a fact of life that they accept despite not being happy about it. For example, they might just work hard to improve their computer security defenses, try to ignore the cyberbullying and the horrific (to their subjective sensibilities) content being distributed over the internet, and simply except that the public goods they create (entertainment, new technology and processes, code, etc.) will simply be copied by others without additional compensation and try to find other funding models if necessary. On the other hand, certain negative consequences might be too much for certain societies that they will be willing to put significant pressure (maybe trade sanctions but perhaps even war) on the other societies to get them to stop. So perhaps the pollution of the air or water supply by a neighboring community is hurting the health of the people in a community, and they decide to actually threaten them with military action (and follow through with the threat if necessary) if they don't stop. So, I imagine we end up with something like a military as well in this system and like today that military threat would likely be used as leverage to get favorable deals that the community wants. And what stops them from abusing this power by escalating from the act of simply stopping the other communities from doing bad things to them (where bad is of course subjective) to the act of coercing other communities into doing beneficial things for them (likely at the expense of the other communities). So maybe they decide they want more of their neighbor's land because of the wonderful resources available there.

As you can see, I like the improvements blockchain technology will bring to justice (more precise rules, better enforceability, and likely more efficient than the current system), but I personally don't believe it is fundamentally different than our current system or that it allows for the removal of a "state" (depends how you define state I guess).

282
No confirmation. It is only in that milestone so that we can consider it after 0.7 and decide if and how to move forward with it. It's ultimate fate could be anything from being closed as wontfix, to actually implementing one of the previous proposals.

Okay, so then we should consider any issues in milestones that come after the earliest milestone at the time as effectively "not (necessarily) on the roadmap"? Can we assume that issues that are in the earliest milestone are issues that the core devs have concluded should be tackled as part of the roadmap (assuming no unforeseen changes)?

283
Notified.
I think the dividend feature is on milestone 0.8 https://github.com/BitShares/bitshares/issues/1430

Well that's a pleasant surprise. Can we get confirmation from Vikram that the dividend feature tentatively scheduled for 0.8.0 is intended to be of a design in which the transaction fee cost to the issuer to issue the dividend is fixed and does not scale with the number of balances holding the UIA?


284
Attempting to maintain 99.9% parity with very high liquidity in a young/thin market without large market makers is the fallacy.   Imagine if we had many market makers like NuBits where the primary difference is that all of the collateral is ON THE BLOCKCHAIN and there are no fractional reserves. 

I think that there needs to be less restrictions, less dependence upon the feed, and less complexity.     BitShares would have a hard time pivoting to a NuBits style market maker unless some major whales step up to the plate and start operating bots.

I think the only reason NuBits can afford the risk of the low-spread market making they do is because they are subsidized by NuShareholders. NuShareholders are willing to dilute their shares to pay for losses of the market maker. So the market maker is able to take higher risk by offering lower spreads despite the fact that NuBits is very new like BitAssets and would otherwise most likely have low liquidity as well. My guess as to why NuShareholders are willing to take on this risk is because they believe this can bootstrap the liquidity so they can continue offering low spreads without immense market making risk (and also because a tighter peg could boost NuBits adoption which they can then profit from by issuing new NuBits for free). But it is a gamble and they could just end up racking up more and more losses, and be forced to make up those losses through more and more dilution, until the whole system breaks down.

Anyway it would be highly inappropriate to put this risk on all BTS holders. But it is perfectly fine if some subset of BTS holders elect to take on this risk for the sake of bootstrapping liquidity and hopefully earning a profit from that activity. I believe most of the benefits would be shared by all BTS holders however, so there is a likely some group trap there.

I'm wondering if CryptoHedge would be interested in taking on this role by issuing a UIA designated to use collected funds for market making on the BitShares DEX. They are already doing this on centralized exchanges between BitAsset/BTC markets.

Pages: 1 ... 12 13 14 15 16 17 18 [19] 20 21 22 23 24 25 26 ... 81