Your question shows the flaw in the NFT and Ordinals design. The fact that everyone is forced into storing data that they do not want and should not even be part of the blockchain.
I don't see the flaw in the NFT/Ordinals design. It's inherent in bitcoin's design, that incentivizes miners to include anything expressible in bitcoin script for a large enough fee. You're not forced to store any data you don't want (just set pruning), but you do need to verify it as a full (i.e. fully verifying) node, just like you must verify all the tons of silly satoshi dice transactions made in the past. If bitcoin is ever to survive in the future where block subsidy is insignificant, then you want any use of the blockchain that people can think of and are willing to pay fees for. Only a competitive fee market can pay for long term security. |
|
|
|
they make a mistake and because of how Bitcoin is designed they can not reverse the mistake and lose their coins. Would it help if payment required the receiver to first prove their ability to spend the funds-to-be-received, before they could actually receive them? |
|
|
|
i found this from adam back's home page that says export crypto sig the code is : -export-a-crypto-system-sig -RSA-3-lines-PERL
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/) i not a coder or developer so asking this , what is meaning of export crypto sig http://www.cypherspace.org/adam/rsa/The guide at http://www.cypherspace.org/adam/rsa/rsa-details.html works for me on my MacOS: $ cat > rsa
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
$ wc rsa
3 7 178 rsa
$ echo "squeamish ossifrage" | ./rsa -k=10001 -n=1967cb529 > msg.rsa
-i used with no filenames on the command line, reading from STDIN.
$ ./rsa -d -k=ac363601 -n=1967cb529 < msg.rsa
-i used with no filenames on the command line, reading from STDIN.
squeamish ossifrage
$
Should work just as well on any Linux system... It encrypts the message by taking numbers modulo 6819722537 (1967cb529 in hex) to the power 65537 (10001 in hex), and decrypts by taking numbers modulo 6819722537 to the power 2889233921 (ac363601 in hex), which gives back the original since 65537 * 2889233921 = 1 mod phi(6819722537). Note that n=6819722537 is the product of two primes p=66593 and q=102409 and thus phi(n) = (p-1)*(q-1). See https://en.wikipedia.org/wiki/RSA_(cryptosystem) for details. The seemingly odd choice of plaintext is explained in https://en.wikipedia.org/wiki/The_Magic_Words_are_Squeamish_Ossifrage |
|
|
|
Can you guess what would be the worst case scenario in case if confidential transactions get introduced after soft-fork in Bitcoin? It depends on implementation details. For example, if you will have Pedersen Commitments, when H is chosen as Point H is defined in nothing-up-my-sleeve fashion (as essentially SHA256(G)) in https://github.com/mimblewimble/secp256k1-zkp/blob/master/src/modules/commitment/main_impl.hL20-L25Discovering log H results in undetectable inflation, i.e. a completely broken system. and blockchain size would increase a lot I doubt it will be the case Correct. The blockchain size could in fact shrink a lot, since in Mimblewimble, spent outputs are not needed for historical verification, so none of that data would be downloaded in the Initial Block Download. Besides the MW UTXO set, only about 100B remain for each MW transaction. This assumes that the same block weight limit applies to the sum weight of the classical block data, the segwit block data , and new MW block data, and that the relative weight of the latter grows over time. |
|
|
|
It is written in the link you wrote, that they decided to create a switch to El GAMAL from MW, and they will push it more if there's QC threat
Maybe this is a recent update that you haven't read
No, you misunderstood. See https://docs.grin.mw/wiki/miscellaneous/switch-commitments/#introducing-switch-commitmentsThey use Pedersen commitments, but the Pedersen blinding factor itself is tweaked (as in taproot) to allow for revealing an additional El-Gamal type commitment. Which potentially allows for a future migration to a post quantum scheme if ECDLP hardness is threatened by quantum computers. |
|
|
|
I take it that Liquid is a side chain that is attached to the Bitcoin Blockchain (like in Lightning network)?
.
Yes, Liquid is a sidechain to Bitcoin. Lightning is *not* a side-chain, but a 2nd layer on bitcoin, meaning that Lightning txs are Bitcoin txs that are simply held until needed, or until obsoleted by updated versions. Ah, when I had a quick read, it seems they created a switch from Mimble Wimble (isn't it MW?) to El GAMAL commitment scheme because
1- MW is perfectly hiding but not perfectly binding (binds value to its commitment)
2-For the case of Quantum Computers threat, El GAMAL scheme although will be broken will protect against supply inflation
(I don't understand this part about inflation, would be grateful if u can explain it if u understand it)
No, MWEB uses Pedersen commitments, not El-Gamal ones. Their MW implementation differs from a pure MW one (such as Grin) in using a hybrid scheme to support non-interactive txs. This hybrid scheme adds a receiver stealth address to every Pedersen commitment (whose blinding factor is also known to the sender) so that only the receiver can spend it. Even if the MWEB side suffers inflation (e.g. due to someone discovering log H), this inflation cannot affect the transparent supply, since the total of all confidential amounts is held in a single transparent utxo. |
|
|
|
Are a blockchain reorganization attack and a 51% attack the same thing? Is 51% of the hashing power necessary for a reorg attack?
Yes, those are essentially the same thing. You can do reorg attacks with less than 51% as well, such as happens with selfish mining. The exact percentage needed depends on various network assumptions and behaviour of other miners. There's a chance not all 51% attacks are reorg ones though as some may try to change other things
Those other things also require reorgs. Avoiding reorgs means always extending the longest (most worked) chain, which is the honest behaviour and thus cannot be called an attack, even if one were to have > 50% of hashpower. With 51%, an attacker can do these things:
1. Reorg previous blocks, removing (and optionally replacing) transactions that have already been confirmed.
2. Censor any or all transactions.
3. Claim all of the block rewards.
2 requires re-orging other blocks that include the txs one wants to censor. 3 requires re-orging ALL other blocks. |
|
|
|
What about using ordinals for legitimate uses? I.e. a simpler and easier notarization of documents inside the mod secure blockchain ever?
I don't see what ordinals offers there beyond what is already provided by https://en.wikipedia.org/wiki/OpenTimestamps |
|
|
|
So, you can mine an invalid block, that is valid in old clients terms, and broadcast it in the old client network. Does that encourage old clients to switch to new version, since they might hear on blocks that are likely to reorg?
The reason that soft-forks work, is that they are enforced by a hashing majority. So in your example, the hashrate majority of miners will ignore the invalid block and will end up reorging it. That's how old clients are forced into the new rules that they're not even aware of. |
|
|
|
tromp wrote something about in their own forum. I believe point 1 and 2 both hold true for Monero as well, not sure about #3 and 4. I think Grin is about the most spam proof chain there is. Where spam is shorthand for inscribed arbitrary data. This is because - Grin is scriptless. So there’s no scripts in which to embed data.
- Grin has no addresses. So you can’t embed data in a pretend address. (you can in other hybrid MW chains like Litecoin).
- Kernels only allow a few bytes of arbitrary data in past lock heights. If you spread such data over many kernels of one tx, then finding them among a block’s sorted kernels is a challenge.
- Outputs only allow some arbitrary data in the rangeproofs, much of which is only retrievable by the owner. Since I don’t understand BPs in detail, someone else will need to say how many bytes could be made publicly visible. It will in any case be a small percentage of the BP size of 674 bytes. And it suffers the same challenge of finding a tx’s outputs among a block’s sorted ones. Finally, it will disappear from most full nodes once the output is spent.
While Monero indeed lacks scripts, 2 doesn't hold for Monero as I noted before: Besides the 32-byte tx_extra field you can also put arbitrary data into each output stealth address (making it unspendable as a side effect). Monero has no time locks, so 3 is irrelevant. Monero does have bulletproofs, so you could store a few bytes there, but unlike Grin, Monero keeps the bulletproofs ordered with the transaction, so it doesn't pose the challenge that Grin does to recover them. The biggest spam threat to Monero is embedding data in fake addresses of many outputs while aggregating the corresponding rangeproofs into one. That would allow over 90% spam... |
|
|
|
Is it possible to create a cryptocurrency in which IP addresses are "staked"?. It is technically possible I'm not sure it is. Blockchain histories must be fully verifiable. How does a future verifier check that some IP address was actively involved and entitled to a reward? |
|
|
|
Monero allows embedding of arbitrary data (aka spam), though only a small fraction of transaction size. Besides the 32-byte tx_extra field you can also put arbitrary data into each output stealth address (making it unspendable as a side effect). Since each output must be accompanied by a rangeproof of 416 bytes for Bulletproof++, this amounts to about 7% of spam, but this percentage would increase by a lot if you aggregate all the rangeproofs of many outputs into one that's only logarithmically bigger. The most spam resistant chain is probably Grin, allowing only a few bytes of spam [1]. [1] https://forum.grin.mw/t/ordinals-on-grin/10336/2 |
|
|
|
The ordinals experiment has clearly shown that you can't stop non-transfer uses within the existing consensus rules.
We have been stopping them successfully before Taproot by making them non-standard which discourages such spam. Otherwise you could create a scriptpub with an arbitrary input that is a little smaller than 1 MB. Pre-taproot, ordinal NFTs could also have used segwit for similar cost. Being non-standard might discourage them, but cannot stop them as long as they can be submitted directly to a mining pool willing to include them, as is happening with ordinals. And even pre-segwit, ordinals could have deployed at a 4x higher cost (without the witness discount). So you're right about being able to discourage them, but wrong about being able to stop them. |
|
|
|
What is i in g0^i mod (q-1)
Like I said, i is an integer ranging from 0 through 18051648 - 1. So the private keys are 1, g0, g0^2 mod (q-1), g0^3 mod (q-1), ... , g0^18051647 mod (q-1). |
|
|
|
They would pay more if Bitcoin got more usage, but at least it was the usage it's indended for and the usage that is actually needed in this world i.e. censorship-free money transfers.
The ordinals experiment has clearly shown that you can't stop non-transfer uses within the existing consensus rules. As long as there's script, and as long as there are addresses, then there are straightforward ways to encode arbitrary data within them. Only a script-free blockchain without adresses, such as Mimblewimble, can strongly limit the amount of arbitrary data, to about 2% of chainsize (using lock heights in the past). |
|
|
|
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). |
|
|
|
|
Show Posts
