Topic: Are these BTC fixes feasible? (Read 1270 times)

You're still wasting everyone's time. Spectacularly. "Let's just stop using independently subjective time syncing altogether" lol


Why should I read anything you've written in any detail at all when I can glance across it quickly and discover obvious nonsense immediately?

No this is what I have said, exactly like what franky said. So maybe you should re-read my posts and stop insulting people.

It is more about your ego than mine, because I don't just go into a thread and start insulting people with no reason.

This is a place about technical discussions not insults.

You literally said nothing like that.

What you did say, which is entirely different, is still written in the thread. Which really demonstrates that this is about your ego, not about Bitcoin. Not interested in your ego.

Yes but the data would pile up and grow quadratically without a limit.

Bandwidth is 1 thing, but when you got a 100 petabyte blockchain and you have to reindex it or do operations with it, it might not be the decentralized node system we have today.

So yes limiting bandwidth and optimizing calculations is good, but you also have to limit the growth of the blockchain.



That is what I was saying, but Banks thinks I am an idiot.

the funny part is. that the 1mb limit was used to help restrict data being transmitted.
if pools are sending out say 4mb of data(cores 4mb weight concept) or 40mb(video's 50k tx concept). then there is no need for the 1mb base rule.
because now the 1mb is not used to limit data/bandwidth. its just limiting old transactions utility/ability to be accepted

also keeping the 1mb base rule but then having 99.99% of tx data outside of the block makes the real data being moved (for 50k tx) something like 40mb of real data..
the only reason to keep the 1mb base would be to prevent people who just want to do old(legacy) transactions.
thus forcing people to move funds to new funky keypairs/transaction types because their old legacy transactions wont get accepted into the base block any more (unless paying a HUGE fee because their 400byte legacy tx is the equivalent to 40 transactions of the new funky style)

keeping the 1mb base rule is more of a controlling the community while directing them down a certain road. rather than any bandwidth limitation security.

the guy doesnt understand the realistic workings of quantum.
binary logic problems would be solved by quantum computer of matching hertz at a 2x rate.

bitcoins PoW has so many hertz that are specifically dedicated to only doing one task (hashrate) that it outpaces a quantum computers at a CPU hert comparison by about 100,000 per asic unit and the network has atleast 130,000 asic units to produce one result every ~10minutes.
so quantum computers need to have 130,000,000,000 more hertz than a common binary PC. which isnt gonna happen any time soon.

more than likely. MANY people will individually make/use quantum asics to distribute and protect the network before one person can accumulate enough to hurt the network.
EG. did nvideo kill off bitcoin back in the GPU days?? nope they sold cards individually to users rather than accumilate their own farm to destroy bitcoin.
did antpool kill off bitcoin back in the first asic days?? nope they sold individual asics to users and kept their farm at reasonable levels

secondly... back to the hack-ability via quantum..
its non binary problems. such as vectors (ECDSA) that quantum computers of matching hertz can solve at a metric of 65,000x rate.

i envision when the keypair curve changes we should not be restricted to one curve, thus mitigating the brute force chances by having more variaty as a defence
eg. instead of everyone picking random coordinates within y² = x³ + 7 one person may have an address that starts
1xxxxxx... which equals y² = x³ + 7  is used
2xxxxxx... which equals y² = x³ + 8  is used
then for instance
4xxxxxx... which equals lets say y² = x³ + 9 is used
6xxxxxx... which equals lets say y² = x³ + 10 is used

or where
1xxxxxx...7(appended to end of address) which equals y² = x³ + 7  is used
1xxxxxx...8(appended to end of address) which equals y² = x³ + 8  is used

or where it may not even need to be y² = x³ + x at all. we can have a huge array of different variables.

thus making it harder for a brute forcer to find all possible combinations, because the elliptic(map) and then resulting fibbonacco(private key) curves would differ
many users have multithreading versions of bitcoin so the whole linear/quadratic processing time has been a laughing stock due to lack of actual regular transactions that needed alot of processing. but should someone malliciously continue making endless blocks of large sigop tx's then multithreading has its advantages, the whole linear/quatratics issue can also be mitigated by just limiting sigops per tx.. or mitigated if segwit is activated (but then thats just a call to war for malicious users to try large sigop tx's to delay old legacy clients)

i personally would not be using unixtime. i would be using blockheight instead.
so should others

miners do include tx's..
but.
here is the explanation of 'empty blocks'
when a block solution occurs the old method is:
to receive all that block data, verify it then verify the solution is also correct. then look at what tx's are confirmed in that block to know what transactions not to include in your next attempt at the next block. this can take upto a couple minutes.

when a block solution occurs the old method is:
instantly start a new empty block hashing while you waste a bit of time verifying someones solution. when confirmed, add unconfirmed transactions to your active attempt.
the thing is some blocks have luck of being solved in just a couple minutes and so thy have not had time to fill the blocks.
the logic is.. while your verifying a solution. why bother powering down your asics and twiddle your thumbs doing nothing for upto 2 minutes

There has been some discussion and evidence that the supposedly random constants of secp256r1 may have been finessed by the NSA.

Edit:
Some reading:
https://bitcointalksearch.org/topic/why-did-bitcoin-choose-secp256k1-over-secp256r1-151120
https://chrispacia.wordpress.com/2013/10/30/nsa-backdoors-and-bitcoin/

I'm won't be discussing anything with you, whether you realise or not, you're wasting everyone's time. Learn about this stuff first, before you start shooting from the hip.




And here's something constructive for you to do: code up this Real Bitcoin of yours, then let the market decide. The internal market of the Bitcoin developer community has long since formed a consensus against this nonsense you're following, so you have no choice but to test your (well, someone else's) ideas on a new coin. I think Real Bitcoin would be a good starting point. Over to you.

What the hell are you talking about, I know what a median is.

I am pointing out the fact that the median of multiple clocks is not necessarily the best decentralized time variable.


It should be the block count itself, since that is on average 10 minutes, and at least that can be agreed upon by all nodes.


Whereas if you have multiple nodes that set their clock to 1500 january 1st 0:00 UTC, the median will be skewed very much.

Just to take one example (out of many), I'm going to have to call you out: you're not sufficiently educated yet to make meaningful comments. Identifying the median involves no arithmetic at all, it's just the middle value in a range of samples. That's statistics 101.

Ask questions, by all means, but if you mindlessly repeat any perceived issue from any Youtube University video, don't expect anyone else to put in more effort than you did.

Probably becuase old wallets used outdated libraries that probably have bugs in them and calculate crypto stuff wrong.



1) NO, i think the way this could be done is by having 2 blockchains.

1 core blockchain, where bitcoin miners and nodes do their job, but only verifying the merkle tree and including transaction.


1 secondary "blockchain",  that is centralized, like an oligopoly of server farms that store the transaction part of the blockchain, and the "core blockchain" would only verify the transactions when spending,


So you have a merkle tree that cryptographically proves the transactions, that is verified by the node when spending, and then it's like archived  on some server farms from where it can be fetched.

So the block can be many megabytes large because it will be either way hosted by a dedicated server. It's only the verification side that would be decentralized to keep the merkle tree honest.

2) I have also read that double SHA256 is not very secure and that HMAC SHA256 would be more elegant and possibly more secure.
https://en.wikipedia.org/wiki/HMAC

4)  I think he was talking about the programming architecture, like how the software runs on 1 thread, so if 1 part of it becomes unresponsive due to DDOS, it freezes it all up.

But if it were multithreaded, you could block DDOS in memory while still doing the other computations on another thread.

I'm no expert programmer but I have done some amateur coding and multithreaded software is always more efficient. A single threaded software doensnt even use up the entire CPU.

5) But why use time at all? Why not just work with the blocks as being 1 unit of time. So 1 block = 1 unit of time, regardless of the interval between them.

We know that over large numbers 1 block will be equal 10 minutes, so why not just use that as a time variable?

What is the point of calculating the median of different clocks?

6) I have no idea about this

In the early days, Bitcoin uses P2PK, Pay-to-publickey. Based on Shor's algronithm, Bitcoin public key which uses ECDSA can be cracked using quantum computing. SHA256 is not susceptible to such things.

Since public key is broadcasted on transactions, the transactions made today exposes the public key. Bitcoin can easily be forked to solve this issue.

gmaxwell discovered a security issue with the R curve while scracthing his head about why Satoshi had opted for the Koblitz curve version of ECDSA instead of the R curve (the R curve is recommended by NIST, whereas the K curve was not). Cannot remember the details, I'm sure someone can.



This character clearly hasn't even read the source code. There's been an ongoing effort to switch from the Boost multi-threading library to the native C++11 multithreading library, even I as a complete amateur coder can understand this sort of basic stuff.

This would only really help SPV wallets, and even so, not all that much as SPV wallets still don't want to download 1 MB of data per block from the network.

This idea is actually both horrible and adds another overhead on top of the existing. First of all, full nodes are still going to have to download the entirety of both blockchains so that they can check that the transactions whose hashes are included in the primary blockchain are actually valid transactions. Blocks in this primary blockchain would contain at most 31250 transactions, ~15 times more than current blocks. That is a lot of transactions and requires a lot of processing power to just verify all of those transactions.

Secondly, there is no limit on how large the secondary blocks are. Someone could make an absolutely massive (on the order of Mb) transaction that would take an extremely long time to verify. That transaction, without any limits on the secondary blockchain, can be as large as the malicious entity wants it to be. Full nodes would still have to download that transaction and verify it. If that transaction does not use segwit, it will essential DoS attack any node which receives that transaction.

Thirdly, those secondary blocks will, with the best case scenario, be ~7 Mb in size. The problem is that this is assuming all transactions are of the average transaction size of 225 bytes. Of course there will be larger transactions, so it will be quite larger than that.

Thus the overhead of such an idea is way too much. Furthermore, why do you have to commit the transaction hashes when that is already done with the merkle root AND the hashes can just be calculated programmatically? There is simply too much overhead with bandwidth and processing power requirements that this is not a good idea at all.

While SHA256 is not a quantum safe algorithm, it will not be "cracked" by quantum computers. There are no ways for a quantum computer to be able to perform a preimage attack on SHA256, they will only be able to find ways to solve SHA256 faster. This just means that the difficulty will increase with the increased hash power brought on by quantum computers. Furthermore Bitcoin's mining algorithm uses SHA256 double (SHA256 of the SHA256 of the block header) and has very strict constraints on what that preimage is, it would still be difficult to quickly find a block even if a preimage attack were found on SHA256.

RIPEMD160 is (relatively) old, but it certainly not outdated nor broken. The only concern here is a collision where the RIPEMD160 of the SHA256 of two public keys is the same. Even so, RIPEMD160 is certainly not broken and 160 bits is still plenty. There are no known collision attacks with RIPEMD160.

I don't know enough about this topic to comment on it.

In what way is the Bitcoin protocol single threaded? It is not even a process that is run but rather a specification of what the messages are. How can it be "multi threaded"?

There is no way to make everyone on the Bitcoin network to use exactly the same current time. All computers will be slightly off of each other due to both latency and physical limitations. Furthermore, forcing everyone onto the same time via a time server introduces centralization.

Currently Bitcoin Core tries to unify time by using the median time of the last 11 blocks. This essentially ensures that all nodes are synced to the right time. AFAIK system time is no longer used for time calculations.

How does he propose to "fix" time syncing?

There is no way around it. You cannot force all miners to make full blocks. There must be a way to make empty blocks otherwise the blockchain can stagnate if there is not enough traffic. Removing the block reward is also plain stupid. There would be no incentive for miners to continue mining as transaction fees are nowhere near high enough to support miners.

How does he propose to "fix" this?

About SHA256 being cracked by quantum computers... as far as I know, bitcoin has it is now is already quantum safe. What I don't remember is the details about how some of the oldest addresses may be prone to get cracked and stolen (the addresses that contain freshly mined bitcoins that never moved). Im not sure if this applies to freshly mined bitcoin in addresses that have 0 transactions, or even in freshly created receiving addresses that have 0 transactions and then leaving the bitcoins there would be at some sort of danger...

In any case SHA256 is whats used in the entire banking industry so if they crack it the whole thing is cracked, also as far as I know we could hard fork to any other algo if that time ever comes.

I saw a video talking about the flaws of Bitcoin and how another altcoin would fix it. It's basically a promotional video for an altcoin, however they did point out a few problems Bitcoin has, but I am not sure how would real Bitcoin technical experts would find it:

This is the video:


1) Removing TX Data (@ 8:00)

One point that interested me was that they claimed that bitcoin should remove all TX data from the block, and only leave the SHA256 of the transaction inside a block. So that the merkle root can be verified.

And then create another protocol, that contains the data, and verify the transaction inside the memory pool, when you create another transaction.


How I imagine this:

Core Blockchain = Merkle Root of Transactions

Secondary Blockchains = Storing the Actual TX data, that only gets verified when another transaction is made in the memory pool, only once instead of twice, to remove burden from the node network.


The video claims that by doing this, the 1 MB block can contain 50,000 transactions.


2) SHA256  (@ 12:00)

He claims at '12 minutes (and a bit before that after 10:07 how he explains how his mining algo is 4x more secure than SHA256) that SHA256 is going to be cracked by quantum computers.

So he proposes Skein and Keccak instead of SHA256:
https://en.wikipedia.org/wiki/Skein_(hash_function)
https://en.wikipedia.org/wiki/SHA-3

He made addresses of his own currency 256 bit strong, instead of 160bit, where he claims that RIPEMD-160 is outdated.


3) Koblitz Curve  (@ 13:10)

At 13:10 he claims that the Koblitz Curve had some signature leakages, so he uses an R curve (571 bit), which he claims that has the highest quantum security to this date.



4) Bitcoin is single threaded  (@ 18:20)

He claims that the bitcoin protocol should be multi-threaded, because a single threated protocol creates a large queue.



5) Bitcoin's time system is bad (@ 19:15)

He claims that Bitcoin's time sync system is bad and that the clocks can be up to 2 hours from eachother.

He claims that this makes BIP 65 (OP_CHECKLOCKTIMEVERIFY) problematic:
https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki


6) Miners don't include TX in their block (@ 21:20)

He claim that BTC miners dont include transactions in their block due to this overhead, instead just go for the block rewards.

---

What are your opinions? He claims that these innovations built and tested on NEXUS can one day be implemented in BITCOIN. So are his ideas feasible.

DISCLAIMER: I'm no technical expert, I am just trying to help Bitcoin by putting good ideas  suggested by others in front of developers.