Bitcoin Forum
May 24, 2024, 01:46:07 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 6 [7] 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 »
121  Bitcoin / Development & Technical Discussion / Re: A Small Subgroup Attack bitcoin on: February 05, 2023, 05:09:45 PM
Could someone enlighten me on this subject because I can't figure out how these 18051648 addresses are generated.

Perhaps reading this paper will help:

https://www.researchgate.net/publication/362472418_Special_Subsets_of_Addresses_for_Blockchains_Using_the_secp256k1_Curve

Section 4 details the generation of addresses from the private keys g0^i mod (q-1), with g0 = 7^{p1*p2*p3}, and 0 <= i < 18051648.
122  Bitcoin / Development & Technical Discussion / Re: NFTs in the Bitcoin blockchain - Ordinal Theory on: February 02, 2023, 01:35:19 PM
Just goes to show the importance of a healthy fee market though.

Or the importance of designing your blockchain so that transactions can include no more free data than what fits in a past lockheight (between 2 and 3 bytes).
123  Bitcoin / Development & Technical Discussion / Re: Why do Bitcoin Addresses exist? on: January 21, 2023, 11:47:16 AM
Yes, it reduces security. Normally, public keys have 128-bit security. In your scenario, they would have 80-bit security, because there would be around 2^95 valid public keys.

Where do you get 95 from, and how does that lead to 80-bit security?

More generally, if outputs show b bits of the public key, and inputs the remaining 256-b bits, then what is the security?
Note that P2PK has the full b=256.
124  Bitcoin / Development & Technical Discussion / Re: Why do Bitcoin Addresses exist? on: January 19, 2023, 02:57:36 PM
  • 2. Addresses take up much less space

They take up 12 fewer byte in the output, but end up taking another 32 byte in the input.
One can imagine another way of shortening output addresses, which doesn't cause redundancy on inputs.

Namely, an output address could be the top 160 bits of the public key. And to spend this output, the corresponding input needs to provide the missing 12 bytes (note that this requires new opcodes). That saves 20 bytes on an output/input pair compared with the current setup. Are there some downsides to this construction?
125  Bitcoin / Development & Technical Discussion / Re: Total amount of hashes on: January 18, 2023, 01:39:01 PM
So you have to multiply this number by the number of pools, as they also calculated hashed, but that work was lost as someone found the nonce first

This is wrong in so many ways, I can't even
126  Bitcoin / Development & Technical Discussion / Re: Why do Bitcoin Addresses exist? on: January 18, 2023, 08:45:34 AM
Grin seemed to bring in some sort of "shuffling" method to reduce traceability by allowing accounts/addresses to move funds and make them less traceable - I don't think mimble wimble fully had a complete level of privacy before that but I could be wrong.

See https://bitcointalk.org/index.php?topic=567625.msg56288711#msg56288711

An implementation for Grin is underway at https://github.com/mimblewimble/mwixnet/
127  Bitcoin / Development & Technical Discussion / Re: How to open channel in Lightning Network on: January 11, 2023, 08:47:29 PM
My understanding is that on the Bitcoin Lighting Network, both parties, the sender, and receiver must make a payment on top of the outgoing and incoming transactions.  Why is that?

Because payment channels work by repeatedly changing the possible payouts of a jointly owned utxo, always ensuring that only the last one is valid.
128  Bitcoin / Development & Technical Discussion / Re: Why do you think G/2 is so strange? on: January 04, 2023, 07:18:54 AM
It's alluding to the fact that you arbitrarily chose to divide G by 2.
It feels like you're trolling. There is almost nothing arbitrary about 1/2; it's the simplest fraction.
I also find it intriguing that the x-coordinate of 1/2 * G, while large in absolute terms,
is so relatively minute. If the people responsible for picking G ever come forward to
explain their choice, I'm sure it will explain the 1 in 10^26 odds that this property
would hold at random.
129  Bitcoin / Development & Technical Discussion / Re: Can't we avoid reorgs once and for all? on: January 02, 2023, 09:09:25 PM
But looking forward, all the work which attempts to find a block, regardless of whether or not that block is accepted, is contributing to the difficulty of finding a block and therefore the security of the network.

I think everyone would agree with that, if we assume that the miner is honest.
I.e. they follow the longest chain rule in attempting to find a block that builds on the block with the most cumulative difficulty.

The remaining questions are:

1) If a new block has been found but not propagated to a specific miner yet, is that miner's attempt wasted?

2) If there are multiple new blocks found nearly simultaneously and both are being mined upon, are the attempts on top of the losing block wasted?

2) should be answered in the negative, since even with two tips at height h (and thus an undetermine height h winner), all the hashpower is still working on finding a block at height h+1,  and the expected time to find one is no longer than if there is a unique tip at height h.

But I would answer 1) in the positive...
130  Bitcoin / Development & Technical Discussion / Re: Can't we avoid reorgs once and for all? on: January 02, 2023, 07:32:10 AM
When there are chain splits, every single hash computed on the losing side of the split is not wasted. They could have been valid blocks, and could have made that side the winning side.
They *are* valid blocks. But they got orphaned, and orphanage is waste. Ideally you want all valid blocks to be building on each other sequentially, preserving every valid block, with the cumulative diff fully reflecting the hashrate. With orphans, the cumulative diff underestimates the hashrate.

This is exactly why shortening the block interval too much, let's say much shorter than a minute, is bad in PoW. Because it increases the orphan rate, and thereby the waste.
131  Bitcoin / Development & Technical Discussion / Re: Replacement for POW on: December 20, 2022, 02:51:34 PM
Actually Doge has no 1/2ings and has a slow steady descending rate of inflation and has the best POW solution to be in alignment with long term development of Fusion power.

Doge did have big reward reductions throughout its first year.
Current rewards (fixed since year 2) are 50x less than at launch.

Only one coin had a fixed reward from launch, 1 coin per second forever [1].

[1] https://bitcointalk.org/index.php?topic=5429497
132  Bitcoin / Development & Technical Discussion / Re: Replacement for POW on: December 20, 2022, 02:22:51 PM
I have seen plenty of new PoW coins created in 2012, and the one thing I noticed is that none had a fair distribution.
Look at all of the people now, they can't even afford to mine btc , so spare me your moral outrage, you have no high ground to stand on.

Quote
Thinking PoW promoted fair distribution of coins, is just pure bullshit.

Fair distribution *requires* PoW. But PoW is not enough. Premines reduce fairness. 100% premines as in PoS reduce it to nothing. As you noticed, reward halvings also reduce fairness.
If Bitcoin didn't have any halvings, it would be as fair as can be expected.
It would no longer have a hard supply cap. But that is not as big a deal as people think [1].

[1] https://john-tromp.medium.com/a-case-for-using-soft-total-supply-1169a188d153
133  Bitcoin / Development & Technical Discussion / Re: Replacement for POW on: December 20, 2022, 07:36:57 AM
Now let's take cardano, it's coins were also created by energy
Wrong; they were created by grift.

Cardano just greedily assigned themselves 100% of all coins and started selling some portion to the gullible.

A major part of being decentralized is to decentralize ownership. Premines run counter to that.

PoS further runs counter to that since it lets everyone just hang on to their share.
134  Bitcoin / Development & Technical Discussion / Re: Replacement for POW on: December 17, 2022, 07:17:36 AM
while bitcoin that has a transaction fee of less than $0.10 is. Grin

Bitcoin, by design of its disappearing block subsidy, will eventually require WAY higher fees than that in order to remain the least bit secure.

So long term, low bitcoin fees are just wishful thinking. It was not designed for that.
135  Alternate cryptocurrencies / Altcoin Discussion / Re: Recipe for Simple Money on: December 16, 2022, 10:25:03 PM
attract investors

There are no investors, only miners.

Quote
write the whitepaper

Already done: https://download.wpsoftware.net/bitcoin/wizardry/mimblewimble.txt

Quote
developer dumping it

They can't because there's no premine.
136  Alternate cryptocurrencies / Altcoin Discussion / Recipe for Simple Money on: December 16, 2022, 07:26:31 PM
Simple emission
    1 coin per second forever. Simply fair. Simply disinflationary. Decentralize the wealth.

Simple block interval
    One minute. 60 seconds. 60 coin subsidy.

Simple consensus
    Proof of Work. Most cumulative difficulty wins.

Simple protocol
    In (pure) Mimblewimble, outputs are Pedersen commitments r*G+v*H
    combining value v and blinding factor r into a single curve point.
    The blinding factor serves both to hide the value and to control ownership.

Simple audit
    Σ unspent-outputs = Σ kernel + offset * G + height * 60e9 * H
    Each kernel is a provable commitment to 0 (as is offset * G)
    height * 60e9 is the expected number of nanocoins emitted in height blocks.

Simple PoW algorithm
    Cuckatoo Cycle. Find a 42-cycle in a huge random graph. Instantly verifiable in 42 lines of code.

Simple Difficulty Adjustment
    diff’ = diff * 4-hours / (4-hours - 60-seconds + last_block_time)

Simple mixing
    CoinSwap can non-interactively mix thousands of self spends each day or hour.

Simple scripting
    No scripts, aka scriptless scripts.
    Supports nearly all Bitcoin script functionality, with none of the complexity:
   multi-signatures, atomic swaps, discreet log contracts, bidirectional payment channels, etc.

Simple implementations
    Small Rust and C++ codebases.

Simple security
    Complexity is the enemy of security. Keep it simple to keep it secure.
137  Alternate cryptocurrencies / Altcoin Discussion / Re: Forever fixed block reward on: December 16, 2022, 01:54:03 PM
Are you looking for coins on the proof of work algorithm or on all modern algorithms?

Only coins without a premine since those have a huge block 0 reward.
I want to know what coins have a pure linear emission (supply = constant * blockheight).
138  Alternate cryptocurrencies / Altcoin Discussion / Re: This forum looks more like Altcoin Price Discussion on: December 16, 2022, 08:14:35 AM
@OP, If you want to discuss technical matters in an altcoins, you can initiate a discussion regarding it on this board by creating a topic.

I certainly could. But with technical discussions making up less than 1% of the volume here, they become very hard to pick out. I only visit this board once a while, and have no hope of quickly identifying the few technical threads that do not discuss price and investment (which are completely boring to me).

I want to see a low volume Altcoin technical Discussion, just like the one for Bitcoin.
139  Alternate cryptocurrencies / Altcoin Discussion / This forum looks more like Altcoin Price Discussion on: December 15, 2022, 07:13:32 PM
Nearly all threads involve some price discussion.

At least on the bitcoin side, you can find some interesting technical discussion in
Bitcoin Forum > Bitcoin > Development & Technical Discussion

I wish there was something similar for altcoins, where no price or investment discussion was allowed...
140  Alternate cryptocurrencies / Altcoin Discussion / Forever fixed block reward on: December 15, 2022, 07:01:49 PM
Which coins have an immutable fixed block subsidy since launch?

I know of one, but wonder if there's any other...
Pages: « 1 2 3 4 5 6 [7] 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!