Transaction

bdb385501bce67658b8520ca7dbd652b68db7ff8df80121ff92ad1d78ee2e72e
Timestamp (utc)
2024-03-22 09:29:13
Fee Paid
0.00000046 BSV
(
0.00914580 BSV
-
0.00914534 BSV
)
Fee Rate
10.16 sat/KB
Version
1
Confirmations
93,844
Size Stats
4,524 B

2 Outputs

Total Output:
0.00914534 BSV
  • j"1LAnZuoQdcKCkpDBKQMCgziGMoPC4VQUckM°<div class="post"><div class="quoteheader"><a href="https://bitcointalk.org/index.php?topic=1790.msg27642#msg27642">Quote from: Hal on December 07, 2010, 04:51:23 AM</a></div><div class="quote"><div class="quoteheader"><a href="https://bitcointalk.org/index.php?topic=2122.msg27612#msg27612">Quote from: FreeMoney on December 07, 2010, 04:06:59 AM</a></div><div class="quote">Whats the general plan here? No reduction in names/block I assume? Won't this make the first blocks incredible valuable and later blocks less valuable as the goodness of remaining names declines? Maybe it should start really low (1?) and move up gradually to a stable amount (100?)?<br/></div><br/>This was on another thread but is relevant here. It is true, the first domain name is likely much more valuable than the millionth. So even if we don't reduce the number of DCC per block, the value will decrease much like Bitcoin does by halving the block reward every two years. That means transaction fees might have to rise substantially over time.<br/><br/>Is it worth considering to increase the block creation rate above 6 per hour? If we generate blocks every 5 minutes or even every 2-3 minutes instead of every 10, that would be another way to speed up domain name availability.<br/></div><br/>One of the reasons to maintain the 10 minute interval between blocks is because of network latency from distant node in terms of "hops" between nodes. &nbsp;If you shorten the interval you risk more "collisions" between nodes that may have simultaneously created a "successful block". &nbsp;In turn that also can make even longer "chains" start to compete against each other.<br/><br/>In other words keeping the 10 minute interval may be a very good idea or even increasing the interval could have benefits. &nbsp;I know of at least some blocks even with this average that have time stamps which even go "negative" where the successive block is timestamped a few seconds <i>before</i> the previous block. &nbsp;More likely it was created at almost the same time but the other block literally was created a matter of a few seconds earlier.<br/><br/>I would like to put in perhaps a more continuous or shorter interval between difficulty adjustments, but then again there are some network attacks which are thwarted by the two-week readjustment system.<div class="quoteheader"><a href="https://bitcointalk.org/index.php?topic=1790.msg27645#msg27645">Quote from: em3rgentOrdr on December 07, 2010, 04:56:51 AM</a></div><div class="quote"><div class="quoteheader"><a href="https://bitcointalk.org/index.php?topic=1790.msg27629#msg27629">Quote from: kiba on December 07, 2010, 04:30:24 AM</a></div><div class="quote">At any rate, do we have enough information that's agreed so that the core hackers can develop right now?<br/></div><br/>Well before starting coding, let's make sure we have the protocol clearly written out. &nbsp;For instance, are we going to take my suggestion of using unitary, non-fractional, bitdnscoins where 1 block == 1 bitdnscoin, instead of having the number of bitdnscoins per block start at 50 and half every few years? &nbsp;Also, there is no need for fractional bitdnscoins since it doesn't make too much sense to own one-tenth of a domain name. &nbsp;Keep in mind that people can use fiat money or even bitcoins when trading unitary bitdnscoins, incase they need to make a trade of two domain names with unequal subjective valuations.<br/><br/></div><br/>The exchanges might really appreciate at least some fractional quantities to play with, although that could also be internal to the exchange itself. &nbsp;The real advantage is for some granularity in terms of competing miners which might want to snag a few additional registrations. &nbsp;It would also help in terms of setting up a per-kilobyte charge for people throwing stuff into the coin transactions too. &nbsp;Attacks on the network can also happen through filling up coin transaction information with useless junk, and charging a fee for that can help stop or at least slow down such a flood attack and at least put cost to such an attack that must be borne by the person making the transaction.&nbsp; Such a charge may require at least some fractional coins, even if it isn't nanocoins necessarily.</div> text/html
    https://whatsonchain.com/tx/bdb385501bce67658b8520ca7dbd652b68db7ff8df80121ff92ad1d78ee2e72e