That's your answer right there -- DLT is a more general term than blockchain. Blockchains are an example of DLT. The difference between those two is that one describes a subset of the other -- like public trains are a subset of public transportation or search engines are a subset of the internet. Therefore DLT and blockchains are not in competition to one another, it's just that the term DLT is more loosely defined than the term blockchain.

Which is probably also why many companies prefer the term DLT over the term blockchain -- from a technological point of view, blockchains are pretty well defined, despite the term being abused in marketing more often than not. The term DLT currently still means pretty much anything, which makes it easier for a company to claim using DLT rather than a blockchain -- because the first is still so vaguely defined that you're technically always correct, no matter how useless the concept. That's the beauty of using a term that both means everything and nothing.

So yeah, if a company says they are working with DLT, that's about as informative as a company saying they are working with the internet. It may be technically correct but doesn't tell you anything about the viability of their venture.

newbie Ferhat.garip: Banned

They are copy / pasting earlier replies within the same thread. Their posts before this copy / pasting started are mostly permutations of "good job" and "i like this project".


Copy:


Original:



Copy:


Original:



Copy:


Original:

Scalability in terms of computation is determined by the amount of time it takes to verify transactions and their signatures which has nothing to do with PoW and is not improved by PoS.

Scalability in terms of bandwidth and storage is affected by transaction size and has nothing to do with PoW and is not improved by PoS.

The only addition I'd really like to see is 2FA support. About the cosmetics I don't care so much to be honest, but I might be a bit old school in this regard.



Seriously though, is this project still alive?

Transaction throughput scalability has nothing to do with whether a cryptocurrency applies PoW, PoS or any other proof of resource.

Anyone claiming such a thing is either lying through their teeth or has no idea what they are talking about.

The transaction amount is irrelevant to the energy expended for securing a PoW blockchain as it has nothing to do with the hashrate.

Ignoring Moore's Law, the energy cost of a blockchain depends on the hashrate which depends on how much miners are willing to pay for electricity. How much miners are willing to pay for electricity, depends on how much the blockchain pays their miners. How much the blockchain pays their miners, has little to do with the transaction throughput, assuming that transaction fees are negligible and mining subsidy ie. block reward is significant.

For example: If a blockchain pays its miners EUR 10,000,000,- a year, and EUR 100,000,- is an acceptable profit, miners will spend EUR 9,900,000,- a year on electricity. If a blockchain pays its miners only EUR 1,000,- a year, and EUR 100,- is an acceptable profit, miners will spend only EUR 900,- a year on electricity. Keep note though, that the latter is much cheaper to attack, thus more vulnerable.

The example above is over-simplified of course and ignores hardware and infrastructure costs, as well as the volatility of cryptocurrencies. I do hope it helps exemplify why transaction throughput is a bad starting point for calculating energy expenditure of PoW based blockchains though.

If I see a post worth meriting, I do so, regardless of rank. Don't expect merits for posts like these:




Pretty much your whole post history consists of posts like these. Except for this thread here, were you now are complaining about not receiving merits for posts such as above.

I'm not trying to critize you, but trying to point you in the right direction. If you improve your post quality, you will be merited. If it's any condolences, you don't even need merits to rank up until Jr Member level. And even then you only need 10 merits to rank up to Member.

It looks like the commit is not part of any branches known to origin. Or at least not of master, which is likely the branch that you have pulled.

If you were here because you are interested in the community and to learn about cryptocurrencies, you probably wouldn't care about merits all that much, because ranks are little more than cosmetics.

If you are annoyed by the merit system, because you're only here for signature campaigns and bounties, I'd say that's proof enough for the merit system working as intended.

Usually I'd say yes, but in the case of BitcoinTalk I'm not so sure.

It would help guiding genuine users to stay well behaved, but once those are out of newbhood they will usually be considerate enough to check post dates first before replying. Our spammer friends on the other hand will simply not care at all and I'm afraid that they are at fault for most necroposts.

So on one hand I'm not sure if it would be all that effective, but on the other hand I wouldn't see much harm done.

If they can send coins from the wallet, the wallet contains the private key. If the wallet doesn't have access to the private key, it can't send any coins.



The Bitcoin blockchain won't check for these limits because it neither knows nor cares about these limits. The other clients won't check for these limits because they as well neither know nor care about these limits. If someone bypasses the send limit on the client side there's nothing you can do about it.

If you really want to have absolute security about the withdrawal limits being enforced, all you can do is create an alt that does so on the protocol level.

Exchanges should keep everything in cold storage to begin with. If you can empty their wallets using their API they already have fucked up security so badly that no rate limiter will be able to help them.



Of course they can, because then they simply increase the withdrawal limit before stealing your coins.



1) Keep track of outgoing transactions within the last 24 hours
2) Whenever a new transaction is made, accumulate the outgoing transaction amount and check against it
3) Publish the new transaction on the blockchain if the outgoing transaction amount is smaller than the withdrawal limit minus the accumulated amount of outgoing transactions within the last 24 hours
4) Otherwise display user message

It's mentioned in the original post:



I'm not sure if such a measure would be all that effective though. Keep in mind that the owner of the coins would be affected by this withdrawal limit as well, which means they would have no way to move their coins to safety should a breach occur -- as the adversary would already have used up the contingent of that daily limit. So while an adversary could not clean out a wallet in one fell swoop, you'd have a daily race between the adversary and the original owner of the coins on who manages to get the daily contingent of coins out first.

Another challenge is the following: How is the limit defined? If it's (a) hard coded as part of the protocol, you have a crippled payment network that depending on the exchange rate supports either only too small denominations or has limits that are too high to make any sense for protection purposes. If it's (b) defined by the address owner, ie. the holder of the private key, the adversary can easily lift the limit up themselves.

DAGs differ from blockchains in that they  store transaction history in a vastly different way.

On blockchains transactions are ordered by concrete checkpoints -- that is, the blocks that confirm a transaction. DAGs don't care all that much for transaction ordering as long as they are not double-spent -- which also seems to be the biggest challenge for DAGs so far.

While most blockchains mitigate double-spends by applying PoW, PoS or other proof-of-resource schemes, DAG-based cryptocurrencies so far rely on centralized, trusted entities -- eg. Iota's coordinator and ByteBall's witnesses.

So far I'm not aware of any decentralized DAG-based cryptocurrencies; I'm not sure whether the need for centralization really is an inherent property of DAG-based cryptocurrencies though.

I love some good speculation as much as the next guy, but it still seems rather unfounded.

Looking at the hashrate of the last 2 years, the growth of mining activity during the last few months hasn't increased more than usual.

https://blockchain.info/charts/hash-rate?timespan=2years&scale=1


Ignoring the big slope during the advent of ASICs, hashrate growth has been fairly stable since late 2011. Looking at 2014 the hashrate seems to grow more than usual in wake of a bubble (could also have been ASIC laggards though), but in itself doesn't seem like a good indicator of future price movements.

https://blockchain.info/charts/hash-rate?timespan=all&scale=1


It is also worth noting that at this point the majority of Bitcoins has already been mined, so investor sentiment will have a larger influence on the Bitcoin price than miner sentiment.

All you could do is make your own hardfork, but then you'd end up with an alt on its own blockchain and not Bitcoin.

If you only write a wallet client that enforces such a limit you would have gained nothing, as you would need to implement such a feature on the protocol level. So while your wallet client would check for such a limit, any adversary that wants to steal coins would simply use a wallet that doesn't enforce it.

Alternatively you could try using timelocked transactions and periodically shuffling coins around on an application level. That would be incredibly kludgy though and not necessarily increase security.

It does indeed look that way. There's a couple of discussions on their GitHub about adding SegWit support, none of which lead to any meaningful results. Their release history also doesn't include anything about P2SH SegWit addresses:

https://github.com/bitpay/bitcore-lib/releases

In part sure, but I wouldn't underestimate the effects of economics of scale.

Large mining operations can stay profitable at lower margins, which in turn makes it harder for smaller miners to remain profitable, further feeding into the profitability and thus growth of large mining operations. I'm afraid this is inevitable with pretty much everything that is turned into a business though.

Decentralization vs scalability vs security seems to be one of many tricky trilemmas, with Bitcoin being the first technology to bring decentralization and security together -- the other two possible combinations having been covered by banks and BitTorrent respectively (amongst others).

So yeah, in the case of cryptocurrencies I fully support decentralization and security over scalability, because otherwise, what's the point? Security is necessary to transmit value, otherwise you can't use it as a money. Decentralization is necessary as a means to an end to achive trustlessness and permissionlessness -- a benefit that centralized solutions do not seem to offer. This leaves scalability as a bit of a stepchild, but that doesn't mean that it can't be improved upon.

The problem when discussing these matter is often that different people have different opinions on (a) what constitutes sufficient decentralization or sometimes even (b) whether decentralization is important at all. Prime example for (a) being the whole Bitcoin vs BCash discussion, AKA "big blocks lead to centralization" vs "payment channels lead to centralization". Prime example for (b) being the likes of Ripple and effectively every ICO ever made, whether they admit it to themselves or not.

Regardless of what your thoughts are on this matter, cryptocurrencies offer something that has been unprecedented so far: Choice. You now have a shitload of currencies to choose from, no matter your preference. Which of these choices will make a real world difference, only time will tell.

Even ignoring RBF and CPFP spamming the network wouldn't guarantee your success though. Sure, you could slow down the whole network, but the specific transaction you are trying to target could by some happy circumstance still slip through the cracks and end up in one of the next blocks.

It is also worth noting that OPs scenario assumes that the transaction is already published. Assuming a reasonable transaction fee this gives a would-be adversary less than 10 minutes (ie. a block interval) to have their spam transactions propagated and validated all over the network. And even then there's a chance that a miner includes transactions that arrived before the spam attack first -- including the targetted transaction.