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.
I'm still wondering how this affects market transactions. Efficient markets must accommodate micro transactions. What would this look like for buy and sell orders? What would be the impact on market-makers?
And how do we deal with this...How do you buy anything with a credit or debit card? They do the same. When a merchant sets up their systems to accept Bitshares they will know that there is a fee taken off what they receive, just the same as if they were accepting cards or paypal or pretty much anything else.
Except that the fee will be different depending on the 'class' of user.
Remember that in the next update it will not be fixed to 101 witnesses. Shareholders can buy as much decentralization as they think is beneficial and worth the cost.With the witnesses being payed by transaction fees ... it doesn't really matter how many there are from the companies perspective .. does it?
EDIT:DSN...
DSN...
https://lightning.network/
At the end of the day, the Lightning Network will end up just as centralized as any other network due to pure economics.
Conclusion: a complex solution compared to BitShares approach that ultimately results in similar centralization and fees and is only fit for transfers.
I read this and my takeaways are:
- Larimer believes all networks become centralized due to economics
- The comparison between bitcoin's lightning and BitShares leaves BitShares in a less favorable light than ever before
- Why hasn't Larimer discussed this "all networks become centralized" economic theory before, such as in his blog?
- Doesn't point #1 ultimately lead us back to a broken, corruptible and centralized clone of the existing mainstream financial system? If not what stops that from happening?
- Does Larimer no longer believe centralization of a global financial ecosystem is a bad thing?
- What are the implications of bitcoin lightning on the future of BitShares? Does it impact the roadmap of 2015 or 2016?
- Following up on delulo's question, how can you have privacy on a public ledger? WHAT is to be held as private and still maintain the value of a public ledger?
QuoteI think the risk is pretty low without "valid_from", and as I said periodic settling keeps it low. Even with "valid_from", you're giving one party disproportional leverage over the other for settling, not actually solving the problem.Even if you do periodic settling the protocol must be extended to support "sessions", otherwise the client will never get its money back and the server will not get paid for the consumed service in case both missed the opportunity to publish their respective transactions.
Also forcing periodic settling has other implications in economics terms since, depending on the settlement frequency, the fees will quickly add up making the service more expensive or not viable at all.
Without forced settlement the server can charge a one time fee (equals to the network fee to publish the transaction) in the first transaction.
I cant see why one party has advantage over the other by using the "valid_form" field.
Every transaction that the client signs could have BTS_BLOCKCHAIN_MAX_TRANSACTION_EXPIRATION_SEC expiration given the server enough time to publish it. And the first transaction that the server gives to the client can have also expiration at MAX ...
It seems that we already have a sort of "valid_from" field already implemented....
Looking at the code in
https://github.com/BitShares/bitshares/blob/master/libraries/blockchain/transaction_evaluation_state.cpp#L145
If we set the expiration of the transaction to T0+3days => valid_from = T0+1days, giving us
valid_from = expiration - 2days
So it seems that we have everything in place to construct micropayments channels with bitAssets!!!!
QuoteI don't think low delegate participation is a serious risk factor in this, and it could be managed by decreasing the update frequency a bit.
If the client loses connectivity, the server will still want to be paid, and should therefore settle using the last transaction. Thus connectivity loss is only an issue if both lose connectivity, or if the remaining connected party refuses to settle. This risk can be mitigated by periodic settling when the stakes reach uncomfortable levels.
I agree with you that the scenario in which both fail to broadcast the transaction is the real issue.
But is kind of a big issue since if that happens the server gets nothing and the client has all his funds locked in the multisig and that should be addressed in the protocol keeping more states in server side.
Don't blame me if I'm being over simplistic here.
But, wouldn't that change (the optional valid_from field) will have a low impact and won't require a hard fork, and will require only a new check in the transaction_evaluation_state::evaluate function?
I don't think low delegate participation is a serious risk factor in this, and it could be managed by decreasing the update frequency a bit.QuoteWith transaction expiration. Ideally, both parties should first sign a transaction distributing the funds back to the client expiring in say a minute, then with that in hand, the client funds the multisig. After 30 seconds (and every minute thereafter), the settling transaction is updated. If one party fails to update, the other settles by broadcasting the last settling transaction before it expires.
The update frequency can increase and decrease depending on value of payments and trust between parties. The initial settling transaction could also include a connect fee to the server to prevent theft of the first 30 seconds service.
That could work and was also my first approach but has some risks.
If for whatever reason the client lost connectivity or the participation rate is low then there is a chance that the refund transaction wont make it to the blockchain and after that the transaction is expired.
So, even if it could work, you will be relaying on connectivity and participation rate.
On the other hand if i have (client) a refund transaction that has a valid_from in the future and a big expiration delta i can use the service with the confidence that in case of problems i will get my money back.
With transaction expiration. Ideally, both parties should first sign a transaction distributing the funds back to the client expiring in say a minute, then with that in hand, the client funds the multisig. After 30 seconds (and every minute thereafter), the settling transaction is updated. If one party fails to update, the other settles by broadcasting the last settling transaction before it expires.I agree this is a great idea. People can always spam the network with invalid transactions with or without this, but they shouldn't be propagated, and the sender should be disconnected when this happens.
I don't think we need "valid_from" for this, just transaction expiration. After funding the multisig, the parties just need to keep updating signed settling transactions shared between them. If the previous settling transaction is about to expire and you don't have a new one yet, broadcast the last one.
Micropayment channels like this are also perfect for mesh networking.
The client will fund a multisig balance, so if the server disappears that money will stay in limbo.
To prevent this the server needs to sign a transaction that sends 100% of the funds back to the client.
Suppose that the valid_from field is not in the transaction.
Then the client will always have a signed transaction from the server that refunds 100% to him.
If i were the client, i will use the service sending signed transactions when the server requires me and after some time i will broadcast the first transaction letting the server with 0 and me with 100%.
This behavior is the one that is prevented by the "valid_from" field.
How will you handle this case without "valid_from"?
