Bitcoin Forum
May 08, 2024, 04:18:26 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 [6] 7 8 9 10 11 12 13 14 15 16 17 18 19 20 »  All
  Print  
Author Topic: DagCoin: a cryptocurrency without blocks  (Read 70789 times)
DumbFruit
Sr. Member
****
Offline Offline

Activity: 433
Merit: 263


View Profile
September 23, 2015, 06:52:49 PM
 #101

I was being a little facetious.
I don't see how this protocol avoids the tradeoff between transactions per second and decentralization, and just repeating the claim isn't helping me understand. You mine on old transaction, ok, so what? How does that help us any more than mining on top of recent transactions in regards to centralization?

100 Mbps allows 12'000 TPS for 1 KiB transactions. There is no an incentive to centralize with conventional hardware. VISA peak TPS is reported to be 56'000 TPS (https://en.bitcoin.it/wiki/Scalability). Average is 2'000 TPS.
If I'm trying to transact in Dagcoin, it doesn't matter to me that maybe 100,000 nodes could potentially have my parent transaction, the only thing that matters to me is finding the node which does have it, and that's where my new transaction is going to go. The next transaction, which relies upon mine, is similarly going to go to that node, and so on. No one wants their transactions left out on a loose strand.
On the flipside, nodes want to get as many transactions as they possibly can because that's presumably where they'll get their revenue in Dagcoin.
So there definitely is an incentive on both sides to centralize the network.

Separately, the amount of bandwidth necessary to store a transaction at VISA is orders of magnitude less than what it costs to propagate a transaction across a network. So if we were looking at your example, and say doing 2000KB/s for an average of 2000TPS, we would need at least 7000 times that bandwidth to propagate over 7000 nodes or 218.75MB/s (1750Mb/s).

Note: I'm using "node" here in the usual sense of the word; a geographically separated mining entity.

By their (dumb) fruits shall ye know them indeed...
1715141906
Hero Member
*
Offline Offline

Posts: 1715141906

View Profile Personal Message (Offline)

Ignore
1715141906
Reply with quote  #2

1715141906
Report to moderator
1715141906
Hero Member
*
Offline Offline

Posts: 1715141906

View Profile Personal Message (Offline)

Ignore
1715141906
Reply with quote  #2

1715141906
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1715141906
Hero Member
*
Offline Offline

Posts: 1715141906

View Profile Personal Message (Offline)

Ignore
1715141906
Reply with quote  #2

1715141906
Report to moderator
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2142
Merit: 1009

Newbie


View Profile
September 23, 2015, 07:11:39 PM
 #102

If I'm trying to transact in Dagcoin, it doesn't matter to me that maybe 100,000 nodes could potentially have my parent transaction, the only thing that matters to me is finding the node which does have it, and that's where my new transaction is going to go. The next transaction, which relies upon mine, is similarly going to go to that node, and so on. No one wants their transactions left out on a loose strand.
On the flipside, nodes want to get as many transactions as they possibly can because that's presumably where they'll get their revenue in Dagcoin.
So there definitely is an incentive on both sides to centralize the network.

Separately, the amount of bandwidth necessary to store a transaction at VISA is orders of magnitude less than what it costs to propagate a transaction across a network. So if we were looking at you're example, and say doing 2000KB/s for an average of 2000TPS, we would need at least 7000 times that bandwidth to comfortably propagate over 7000 nodes or 218.75MB/s (1750Mb/s).

Looks like we are talking about different DAG-coins. My version of DAG doesn't care about network topology.


Separately, the amount of bandwidth necessary to store a transaction at VISA is orders of magnitude less than what it costs to propagate a transaction across a network. So if we were looking at you're example, and say doing 2000KB/s for an average of 2000TPS, we would need at least 7000 times that bandwidth to comfortably propagate over 7000 nodes or 218.75MB/s (1750Mb/s).

Let's check your numbers. IP header size = 40 bytes, UDP header size = 8 bytes, transaction size = 1024 bytes. 40 + 8 + 1024 = 1072. Small world topology with 3 neighbors (this is enough to effectively propagate data) requires to send 3 times of that, which is 25'728 bits. For 100 Mbps we get 3'886 TPS. And this is without multicast enabled on routers between nodes.
monsterer
Legendary
*
Offline Offline

Activity: 1008
Merit: 1002


View Profile
September 23, 2015, 07:26:07 PM
 #103

Looks like we are talking about different DAG-coins. My version of DAG doesn't care about network topology.

Start a different thread, this is for DagCoin the whitepaper.
DumbFruit
Sr. Member
****
Offline Offline

Activity: 433
Merit: 263


View Profile
September 23, 2015, 09:14:46 PM
 #104

Looks like we are talking about different DAG-coins. My version of DAG doesn't care about network topology.
We're definitely on different pages here. I don't know anything about this thing of yours.

Small world topology with 3 neighbors (this is enough to effectively propagate data) requires to send 3 times of that...
You're not going to be able to "effectively" propagate that transaction in 1 second to 7000 nodes with 3 neighbors. You would never have distributed consensus among those nodes. If user's can't get distributed consensus, then they will gravitate toward the subset of node(s) which has(have) the closest thing to it.
I don't see how DagCoin avoids this issue, and I stress that I'm talking about the DagCoin in this thread and not "a DAG coin" in general. Though I'm skeptical of the latter as well..

By their (dumb) fruits shall ye know them indeed...
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2142
Merit: 1009

Newbie


View Profile
September 23, 2015, 09:25:23 PM
 #105

You're not going to be able to "effectively" propagate that transaction in 1 second to 7000 nodes with 3 neighbors. You would never have distributed consensus among those nodes. If user's can't get distributed consensus, then they will gravitate toward the subset of node(s) which has(have) the closest thing to it.

Why 1 sec, not 1 min?
Consensus among nodes is not required, it's perpendicular to consensus about ledger state.
I can't comment on the gravitation thing without knowing what reference strategy is being used in your scenario, I know at least one strategy that doesn't lead to fragmentation.
DumbFruit
Sr. Member
****
Offline Offline

Activity: 433
Merit: 263


View Profile
September 24, 2015, 02:55:00 AM
 #106

You're not going to be able to "effectively" propagate that transaction in 1 second to 7000 nodes with 3 neighbors. You would never have distributed consensus among those nodes. If user's can't get distributed consensus, then they will gravitate toward the subset of node(s) which has(have) the closest thing to it.

Why 1 sec, not 1 min?
Consensus among nodes is not required, it's perpendicular to consensus about ledger state.
I can't comment on the gravitation thing without knowing what reference strategy is being used in your scenario, I know at least one strategy that doesn't lead to fragmentation.
I assume you mean "why not 2000 transactions per minute?" Sergio says himself that it's only limited by the hardware deployed.

Quote from: Sergio Demian Lerner
As there are no free-rides for transactions, the transaction/rate is limited by existent deployed computing power and electricity cost.

He then goes on to talk about the problems with increasing difficulty on transactions in this system;

Quote from: Sergio Demian Lerner
By time-stamping every transaction, one could dynamically adapt the difficulty of the proof-of-work to achieve more fixed rate. But if the difficulty of a transactions depends on the difficulty of the parent transactions, then there may be incentives to choose old parent transactions instead of new ones to reduce the PoW required, if the current rate is over the fixed rate. Just to be sure Moore's law does [sic] permit spamming in the future, one could embed a re-targeting rule such that every 18 months the difficulty is doubled. It seems preferable that the last M transactions (such as M=10K) of a certain transaction vote on an increase or decrease of the difficulty of the following transactions (with small step changes). Then users could vote more freely on how the network should work without having any immediate benefit to bias voting. This is a similar problem as the current Bitcoin block-chain increase problem: only miners can vote, because user votes are prone to Sybil attacks. In DagCoin, every user can vote, as long as it transact.

I'd like to point out that in DagCoin, it is still only miners that vote. If you're a user that applies work on a transaction and broadcasts it, then you're a miner.
Work is a waste from the perspective of the miners. There is no incentive, or even a method to incentivize miners to do work on transactions in DagCoin. Competition would atrophy hashpower on the network in order to drive up transaction speeds, which is the product that the miner provides, users enjoy, and the only method of remuneration. Mining is just a cost that the miner wants to minimize.
This is just like if we removed the block size limit from Bitcoin and removed the subsidy.

That problem, the lack of funding for difficulty increases in order to slow down transaction speeds, isn't referenced in the white paper unless I missed it. So ultimately to get back to answering your original question "Why 1 sec, not 1 min?" the answer is I don't see any decentralized throttling mechanism that could actually work in DagCoin.

By their (dumb) fruits shall ye know them indeed...
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2142
Merit: 1009

Newbie


View Profile
September 24, 2015, 05:02:16 AM
 #107

Competition would atrophy hashpower on the network in order to drive up transaction speeds, which is the product that the miner provides, users enjoy, and the only method of remuneration. Mining is just a cost that the miner wants to minimize.

If miners == users then I suggest to use a digital signature algorithm which security depends on PoW tied to the transaction. Those who generate little PoW may see their coins double-spent by others.
monsterer
Legendary
*
Offline Offline

Activity: 1008
Merit: 1002


View Profile
September 24, 2015, 07:05:58 AM
 #108

If miners == users then I suggest to use a digital signature algorithm which security depends on PoW tied to the transaction. Those who generate little PoW may see their coins double-spent by others.

And so users with slow computers will simply stop using the platform, creating a centralisation of its own form - this is especially bad if difficulty is out of the control of the users, which in this paper it appears to be.
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2142
Merit: 1009

Newbie


View Profile
September 24, 2015, 08:35:35 AM
 #109

And so users with slow computers will simply stop using the platform, creating a centralisation of its own form - this is especially bad if difficulty is out of the control of the users, which in this paper it appears to be.

Low security transactions are secured once they are included into the graph, doublespending becomes hard after that point. It's a CPU vs bandwidth tradeoff. Users with very slow computers and very slow Internet will indeed be unable to use the platform unless they cooperate with each other (via multisignatures).
monsterer
Legendary
*
Offline Offline

Activity: 1008
Merit: 1002


View Profile
September 24, 2015, 08:50:37 AM
 #110

Low security transactions are secured once they are included into the graph, doublespending becomes hard after that point. It's a CPU vs bandwidth tradeoff. Users with very slow computers and very slow Internet will indeed be unable to use the platform unless they cooperate with each other (via multisignatures).

A discriminatory protocol is worse than mining centralisation IMO because you exclude use in countries which would stand to gain the most.
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2142
Merit: 1009

Newbie


View Profile
September 24, 2015, 08:53:24 AM
 #111

A discriminatory protocol is worse than mining centralisation IMO because you exclude use in countries which would stand to gain the most.

Agree, luckily for us our design solves this issue in a sidechain-like manner.
onemorexmr
Sr. Member
****
Offline Offline

Activity: 252
Merit: 250



View Profile
September 24, 2015, 08:56:30 AM
 #112

i must admit i dont understand how this TxNet may work in detail but it sounds interesting.

i have one question though (this also assumes no further tx-obfuscation):
if tx's are mined like blocks with multiple ancestors is it possible to blacklist certain transactions in different jurisdictions and still have the rest working?

only transactions which uses that outputs would be unusable in that country.

any thoughts?

XMR || Monero || monerodice.net || xmr.to || mymonero.com || openalias.org || you think bitcoin is fungible? watch this
monsterer
Legendary
*
Offline Offline

Activity: 1008
Merit: 1002


View Profile
September 24, 2015, 09:08:10 AM
 #113

Those who generate little PoW may see their coins double-spent by others.

To clarify, you're talking about being a lower part of a chain which gets orphaned here, not weak cryptographic security?
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2142
Merit: 1009

Newbie


View Profile
September 24, 2015, 09:19:07 AM
 #114

To clarify, you're talking about being a lower part of a chain which gets orphaned here, not weak cryptographic security?

I'm talking about weaker cryptographic security. More PoW done -> stronger the signature is (harder to find another message to sign).
monsterer
Legendary
*
Offline Offline

Activity: 1008
Merit: 1002


View Profile
September 24, 2015, 09:25:54 AM
 #115

I'm talking about weaker cryptographic security. More PoW done -> stronger the signature is (harder to find another message to sign).

More POW = stronger block hash, but you should never be able to forge a signature.
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2142
Merit: 1009

Newbie


View Profile
September 24, 2015, 11:34:15 AM
 #116

you should never be able to forge a signature.

Why?
monsterer
Legendary
*
Offline Offline

Activity: 1008
Merit: 1002


View Profile
September 24, 2015, 01:37:43 PM
 #117

you should never be able to forge a signature.

Why?

If I sign a msg with my private key, the signature is a record that I signed the msg. If you can forge my signature, then you can send fake msgs from me.
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2142
Merit: 1009

Newbie


View Profile
September 24, 2015, 01:44:26 PM
 #118

If I sign a msg with my private key, the signature is a record that I signed the msg. If you can forge my signature, then you can send fake msgs from me.

This signing algorithm is supposed to be used in a PoW cryptocoin only. Every key can be used only once (every output can be spent only once).
monsterer
Legendary
*
Offline Offline

Activity: 1008
Merit: 1002


View Profile
September 24, 2015, 01:50:54 PM
 #119

This signing algorithm is supposed to be used in a PoW cryptocoin only. Every key can be used only once (every output can be spent only once).

What signing algorithm? I feel this is so far off topic now, that you really should start your own thread about your own design.
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2142
Merit: 1009

Newbie


View Profile
September 24, 2015, 01:52:13 PM
 #120

What signing algorithm? I feel this is so far off topic now, that you really should start your own thread about your own design.

I wasn't going to discuss that algorithm at all, but you were asking about it Smiley
Pages: « 1 2 3 4 5 [6] 7 8 9 10 11 12 13 14 15 16 17 18 19 20 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!