|
1122
|
Bitcoin / Bitcoin Discussion / Re: On Ordinals: Where do you stand?
|
on: February 24, 2023, 10:14:40 AM
|
But in first place, who would bother implement such feature? Even if someone decide to implement it and make PR request, would it be accepted by maintainer of certain full node software?
The "make OP_RETURN completely ignorable" (=not even necessary for block validation) part would have to be of course a BIP. You can make BIP first, but Bitcoin Core or other full node software doesn't have to implement such feature. If I remember it well, some altcoins like NXT have/had(?) such a feature.
I don't know about NXT, but centralized cryptocurrency might have such feature. The notify-and-take-down system however could be a separate software using Bitcoin Core's RPC interface, which could be provided by third-party developers; most likely simple Python scripts would be enough. The only thing Bitcoin Core would have to provide is a command like "delete OP_RETURN data from transaction X", and that would have to be part of the BIP.
I understand your explanation. But full node operator is unlikely to use such feature and feature specific for Bitcoin Core doesn't need BIP. "Destructive" attackers wanting to "poison" the blockchain would for sure go for another methods: if Taproot is restricted, then use (as I already wrote) methods like fake addresses and amounts.
That's possible, but don't forget it's more expensive since they doesn't get witness "discount". |
|
|
|
|
1123
|
Bitcoin / Development & Technical Discussion / Re: Blockchain reorganization attack
|
on: February 23, 2023, 11:56:52 AM
|
Are a blockchain reorganization attack and a 51% attack the same thing?
Slightly different. The former refer to type of the attack, while the latter refer to how to perform an attack. Is 51% of the hashing power necessary for a reorg attack?
No. But 51% of hashrate ensure success of your attack. An attacker is not required to have 51% in order to force a reorg, but the probability of success drops very quickly with lower hash rate and more blocks. This is why it is recommended to wait for additional confirmations if there is a risk due to a reorg.
They could force a reorg if they own most of the networking infrastructure, since Bitcoin Core packets are unencrypted (unless you use Tor to connect to it), they will be able to read any packet they want and drop some of them, preventing the relaying to a large portion of nodes of mined blocks that the operator don't like until other blocks are mined. Jam enough blocks, and you can cause a mempool congestion, possibly even dropping transactions if the total size is over 300MB. Even Hetzner could (theoretically) do this as they own a large percentage of nodes. If it fails, it would cause a chain split and would be even more destructive than a few reorged blocks (as transactions inside would go back into the mempool). I'm not even sure Hetzner could theoretically do that when, 1. Most pool have it's own infrastructure, especially for fast block propagation (e.g. FIBRE and Falcon). 2. Decent amount of node (which accept incoming connection) use Tor. 3. Only 6.1% (which accept incoming connection) Hetzner. 4. Bitcoin Core connect to 10 other nodes and try to diversify it based on IP block. P.S. I use https://bitnodes.io/dashboard/ as primary reference. |
|
|
|
|
1124
|
Bitcoin / Bitcoin Discussion / Re: On Ordinals: Where do you stand?
|
on: February 23, 2023, 10:24:41 AM
|
~
You are correct about the limit of OP_RETURN as @ETFbitcoin pointed out but you are forgetting that the examples you used (documents related to ownership of a car or a house, etc.) has centralization attached to it so you don't need to store the whole document on bitcoin blockchain, but only some sort of link to it like a serial number or document hash, etc. and OP_RETURN's 80 byte limit is more than enough for that purpose. Here is an example of real world application. Land registry by the government of Georgia using bitcoin blockchain: https://www.forbes.com/sites/laurashin/2017/02/07/the-first-government-to-secure-land-titles-on-the-bitcoin-blockchain-expands-project/And even for decentralized/distributed service, you don't have to store the data on Bitcoin blockchain. You could just replace URL/document hash with BitTorrent magnet link, IPFS hash or even TXID on sidechain/altcoin. It's funny that the Wired article also mentions a possible solution that I've thought about a bit in the last days. One could make OP_RETURN data completely deletable, for example if their hash is recorded separately. In this case, even a "notify and take down" system could be implemented. The problem would perhaps be that the set of nodes offering the "full" blockchain with the data would decrease, in an extreme (but in the case of BTC, unlikely) case even to zero.
But in first place, who would bother implement such feature? Even if someone decide to implement it and make PR request, would it be accepted by maintainer of certain full node software? |
|
|
|
|
1125
|
Bitcoin / Bitcoin Discussion / Re: On Ordinals: Where do you stand?
|
on: February 22, 2023, 09:56:08 AM
|
--snip--
You could already do that using OP_RETURN as it has been done before. All it takes is one transaction with an OP_RETURN output containing the information related to the documents proving possession of the thing in real world.
If I am not wrong there are limits of data in each OP_RETURN with the need of splitting the data in multiple transactions. --snip-- Correct, one transaction only allow single OP_RETURN with maximum size 80 bytes. If you want to store more data, you either need to create multiple transactions or create non-standard transaction (size higher than 80 bytes and/or multiple OP_RETURN) and ask miner/pool to include it manually. Meanwhile outside the bubble --snip-- Data kept by lukedashjr shows the Bitcoin node count is up 12.5% this year, the largest increase since Jan 2021. Wonder why that is... One of the reasons would be ord software require you to run Bitcoin Core. |
|
|
|
|
1126
|
Bitcoin / Development & Technical Discussion / Re: NFTs in the Bitcoin blockchain - Ordinal Theory
|
on: February 21, 2023, 11:51:04 AM
|
Also: why should I commit a crime for someone else just because they pay me? That's not a moral concern, but a legal. And I'm still curious how you can prevent the inclusion of illegal content without preventing the inclusion of any content that is valid but just non-standard. To be honest, switching to scriptless or a heavily restricted scripting language, seems unrealistic for Bitcoin. So I'm not sure how to implement it; just saying that it is technically possible, because others are already doing it. It's definitely unrealistic when you consider backward compatibility and notable usage which rely on script (such as LN and sidechain). As for implementation, AFAIK it should be possible by creating new standard (with more strict scripting) which use SegWit version 2 (version 0 refer to "default" SegWit and version 1 refer to Taproot) where it's address use prefix bc1z. That's true. So attacking Bitcoin through NFTs is much more probable and much riskier than through the attack I presented. Which makes it much more important to protect against it...? Or not? Hard to say. But at least, it's an attack which should be prevented when you believe Bitcoin should be either mainly/mostly/only used as currency or payment method. I definetly want to play with this.
I have some basi questions like: is there an official, or rather a de facto marketplace for ordinals?
If I wan tot buy an NFT on the ETH blockchain, I go to opensea.io: is there an equivalent market for the bitcoin blockchain?
One method i know is use wrapped Bitcoin and buy Ordinals NFT on opensea.io. |
|
|
|
|
1127
|
Bitcoin / Development & Technical Discussion / Re: one ip one vote
|
on: February 21, 2023, 11:35:15 AM
|
I think it's possible with ipv4 addresses.
Why do you think it's possible? How about IPv6?
a cryptocurrency cannot be more decentralized than the internet itself.
Do you imply cryptocurrency isn't really decentralized? ICANN have some influence towards internet centralization
It is perhaps a flawed proposal by Satoshi, but fortunately Gavin and the core team of developers ironed those issues out shortly after his disappearance.
It's not proposal, saotoshi simple mention weakness of one-IP-address-one-vote. Here's whole paragraph which contain sentence mentioned by OP. The proof-of-work also solves the problem of determining representation in majority decision making. If the majority were based on one-IP-address-one-vote, it could be subverted by anyone able to allocate many IPs. Proof-of-work is essentially one-CPU-one-vote. The majority decision is represented by the longest chain, which has the greatest proof-of-work effort invested in it. If a majority of CPU power is controlled by honest nodes, the honest chain will grow the fastest and outpace any competing chains. To modify a past block, an attacker would have to redo the proof-of-work of the block and all blocks after it and then catch up with and surpass the work of the honest nodes. We will show later that the probability of a slower attacker catching up diminishes exponentially as subsequent blocks are added.
|
|
|
|
|
1128
|
Bitcoin / Development & Technical Discussion / Re: Combination of Paper, MOF and AI can provide ultra military grade protection
|
on: February 20, 2023, 11:52:29 AM
|
I briefly skimmed all source you mentioned, but apparently there's no mention how long material of this invisible ink could last. It would be nightmare to try recover your paper wallet, but found out the invisible ink is partially or fully gone which makes recovery impossible. Invisible ink is only useful if the attacker doesn't know it is there and doesn't consider looking for it, or doesn't have the means to reveal it.
And third source mentioned by OP mention the invisible ink can be revealed with UV light which is easy to obtain. |
|
|
|
|
1129
|
Bitcoin / Bitcoin Discussion / Re: Private keys posted on Bitcointalk
|
on: February 20, 2023, 10:38:51 AM
|
This morning, Bitcoin Core was hanging. I killed it, restarted it, and it took forever to load the wallet (which had grown to 2.2 GB during the rescan).
FYI, Bitcoin Core load whole wallet to RAM which may be reason of long loading time[1]. I think that the number is bigger, since some have posted them as images which you could not "scan". My list is indeed not complete. I didn't search for Hex keys either, only WIF. And with HEX, i expect you'll receive many false positive since 64 character HEX also mentioned as hash of a file, as block hash, as TXID or explaining SHA-256. Coming from a newbie account? It may be intentional, some greedy members will want to outsmart the poster but the smart will get hunted in the end, I don't go after people's private keys or recovery seeds when I see them online, I believe no one is stupid enough to post them online, they did it to lure greedy people.
That doesn't make sense. Bitcoin don't have smart contract which can be used to perform scam through sharing recovery/mnemonic words. [1] https://bitcointalk.org/index.php?topic=5400538.msg60252176#msg60252176 |
|
|
|
|
1131
|
Bitcoin / Development & Technical Discussion / Re: NFTs in the Bitcoin blockchain - Ordinal Theory
|
on: February 20, 2023, 09:48:18 AM
|
But unlike creating an NFT/Inscription, loop of sending Bitcoin between 2 address won't make you any money. Debatable. Some billionaire could execute this attack by the impression that it'll ruin Bitcoin's image. That's possible, but it doesn't change such attack won't make you any money. Although it's different case if that billionaire got paid or think running Bitcoin image would make people move to their centralized coin or their service. Another method to mitigate such attack is making TX which push data (using Taproot OP_FALSE OP_IF OP_PUSH) higher than X bytes become non-standard. It's already discussed by some Bitcoin Core contributor on early February[1] Sure, you can configure your node to accept whatever it wants, but that won't stop you from Ordinal fans who'll pay miners include their transactions that pay more. I'm questioning if it even does anything if there's real demand for it. That's true, but it'd discourage some people since it'll be more expensive and take more time (e.g. only some pool offer such service and copy-paste raw signed transaction to miner's website). Miners shouldn't follow non-standardness, but pure profit.
But on other hand, including non-standard transaction would bring additional complexity to their software which might not be worth it. For example, there's very few pool willing to include transaction created with uncompressed segwit address. What if I decide to write a script and spend a few BTC to just send transactions between 2 wallets of mine at 1000sat/vB and render Bitcoin unusable (without paying more than 1000sat/vB to send a transaction)? But unlike creating an NFT/Inscription, loop of sending Bitcoin between 2 address won't make you any money. So? Sure, I would waste my money doing that, but render Bitcoin basically useless. There are certainly people with such a goal in mind with enough money to do it. I suggest that we look into protecting against attacks, instead of shrugging them off, just because they follow Bitcoin protocol. My point is there are far less people willing do that. As for protection against such attack, one possible option is dynamic blocksize and neutral fee which implemented on Monero[1]. Another option is modifying behavior on old version of Bitcoin-Qt which determine free transaction based on coin age, expect it's implemented on protocol level. [1] https://monero.stackexchange.com/a/4567[2] https://en.bitcoin.it/wiki/Miner_fees#Priority_transactions |
|
|
|
|
1133
|
Bitcoin / Development & Technical Discussion / Re: NFTs in the Bitcoin blockchain - Ordinal Theory
|
on: February 19, 2023, 12:27:19 PM
|
What if I decide to write a script and spend a few BTC to just send transactions between 2 wallets of mine at 1000sat/vB and render Bitcoin unusable (without paying more than 1000sat/vB to send a transaction)? What do you suggest to happen in that scenario? Censor those? I don't think we have a protection against that, either. Much harder problem than here, since those would be 'legitimate' regular transactions. But unlike creating an NFT/Inscription, loop of sending Bitcoin between 2 address won't make you any money. Just saying that there are ways to attack Bitcoin and if there are easy mitigations that still allow us to have full freedom in its usage as a payment system, they should be considered. What's the best method we have to mitigate from these attacks? My best guess is to educate and convince users that Ordinals are nonsense. We definitely can't prevent an attacker from executing this, though. They would disagree if they want their own data become immutable or hearing people making profit by selling Ordinal's NFT. Another method to mitigate such attack is making TX which push data (using Taproot OP_FALSE OP_IF OP_PUSH) higher than X bytes become non-standard. It's already discussed by some Bitcoin Core contributor on early February[1]. [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021435.html |
|
|
|
|
1134
|
Bitcoin / Development & Technical Discussion / Re: how to get block height for given day
|
on: February 19, 2023, 11:58:49 AM
|
Can you do by just subtracting 144 from the block height per day you're looking?
This is wrong approach. Current all-time average block time is somewhere about 9.55 minutes. If not, I'd still recommend doing that and then looking up the api for a block explorer (like blockchain.com) and trying to programmatically go back (or forward) from there based on how many blocks would have come since. I remember blockchain.com's api indexing blocks based on height and hash (not sure how others do it but it's probably an easy enough place to start and get a json of data, and then checking the time the block was received or generated).
Unfortunately blockchain.com API doesn't have filter to choose block based on date. Here is another fun way of doing it which is a lot faster and cheaper to do: If you run a SPV client like Electrum on your computer you already have all the block headers saved up in a ~60 MB file called "blockchain_headers" which is a stream of bytes. All you have to do is to programatically read this file to get the raw bytes which should be a multiple of 80. Each 80 byte is a block header of a block in chronological order (so you have the block height this way too). Then start from the beginning (byte 0) and extract the time from each 80 byte chunk (ie. one header) knowing that 4th item in it is the timestamp. version[4] + prev_hash[32] + merkle_root[32] + time[4] + target[4] + nonce[4]
Here is a pseudocode stream = File.Read("blockchain_headers")
while(stream.HasBytesLeft)
stream.Skip(68)
timestamp = stream.Read(4).ConvertToTime_LittleEndian()
resultList.Add(timestamp)
stream.Skip(8)
Now all you have to do is search in the list of timestamps to see when the day in the datetime you converted changes to get the last height of the day. The height is the index of the datetime inside the resultList/array. Keep in mind that timestamps are in UTC not your local time. Do you mind checking beginning of file blockchain_headers with hex editor/viewer? I tried on my device, but mostly it only contain zeroes. I suspect Electrum only request needed block header rather than all block header.   |
|
|
|
|
1135
|
Bitcoin / Development & Technical Discussion / Re: Unique serial number for every single satoshi
|
on: February 19, 2023, 09:52:32 AM
|
Creating BIP or consult with other Bitcoin developer is totally optional choice since Bitcoin supposed to be decentralized. IMO there's no need to do that when ordinals doesn't require any change on Bitcoin protocol or full node software.
from what i've heard and what i can tell, this ordinals thing is just using a loophole in the transaction witness size to store data. probably not how it was intended to be used. At very least, i never hear anyone promote Taproot to store arbitrary data/used to create NFT before Taproot is activated. didn't they once reduce the size of OP_RETURN when people was abusing that? well hopefully that doesn't happen here or it's goodbye ordinals. nice knowing ya.
The only change i'm aware is changing limit from 40 bytes to 80 bytes. But such limit only makes the transaction become non-standard and can be bypassed by asking miner to include their transaction manually. Other usage which insert arbitrary data to Bitcoin blockchain (such as RSK sidechain merge mining) have no BIP either.
well you got me on that one because i'm not too familiar with that whole topic. Here's some reference (for RSK merge mining) in case you're curious, https://dev.rootstock.io/rsk/architecture/mining/https://dev.rootstock.io/rsk/architecture/mining/implementation-guide/ |
|
|
|
|
1136
|
Bitcoin / Development & Technical Discussion / Re: Unique serial number for every single satoshi
|
on: February 18, 2023, 11:49:39 AM
|
Two months from my earlier post, it looks like ordinals are doing just that. It's a pleasant surprise, considering that implementation (coding) was accomplished almost singlehandedly by one guy, and not by the Bitcoin Core developers at all.  usually when some new feature is added to bitcoin it has to go through some type of an approvals process. that happens by someone making a BIP and then it might get implemented by the devs if they agree it would make a useful addition to bitcoin. ordinals didn't happen that way. so we really don't know if ordinals was meant to exist or not. because the devs didn't have a chance to consider it before it just came into existence. Creating BIP or consult with other Bitcoin developer is totally optional choice since Bitcoin supposed to be decentralized. IMO there's no need to do that when ordinals doesn't require any change on Bitcoin protocol or full node software. Other usage which insert arbitrary data to Bitcoin blockchain (such as RSK sidechain merge mining) have no BIP either. |
|
|
|
|
1137
|
Bitcoin / Development & Technical Discussion / Re: generate random number
|
on: February 17, 2023, 01:00:38 PM
|
I don't know what is your main goal. But i did quick change to your code and this should do what you want. import random
elements = []
while len(elements) < 100:
selection = random.randint(1, 100)
print(selection)
if selection not in elements:
elements.append(selection)
print(elements)
Here's snippet of the output, 22
[22]
14
[22, 14]
...
76
[22, 14, 4, 45, 39, 51, 36, 30, 94, 41, 73, 32, 89, 100, 64, 18, 6, 16, 46, 52, 98, 71, 58, 62, 33, 17, 29, 56, 9, 25, 83, 53, 28, 72, 37, 86, 31, 61, 15, 26, 99, 70, 84, 66, 93, 79, 48, 34, 78, 90, 97, 49, 75, 54, 55, 13, 85, 20, 7, 96, 81, 68, 57, 60, 74, 11, 91, 69, 1, 40, 65, 21, 12, 63, 87, 5, 92, 77, 24, 44, 67, 3, 8, 35, 50, 42, 38, 23, 10, 76, 95, 2, 59, 27, 47, 82, 88, 19, 43]
80
[22, 14, 4, 45, 39, 51, 36, 30, 94, 41, 73, 32, 89, 100, 64, 18, 6, 16, 46, 52, 98, 71, 58, 62, 33, 17, 29, 56, 9, 25, 83, 53, 28, 72, 37, 86, 31, 61, 15, 26, 99, 70, 84, 66, 93, 79, 48, 34, 78, 90, 97, 49, 75, 54, 55, 13, 85, 20, 7, 96, 81, 68, 57, 60, 74, 11, 91, 69, 1, 40, 65, 21, 12, 63, 87, 5, 92, 77, 24, 44, 67, 3, 8, 35, 50, 42, 38, 23, 10, 76, 95, 2, 59, 27, 47, 82, 88, 19, 43, 80]
|
|
|
|
|
1138
|
Bitcoin / Bitcoin Discussion / Re: On Ordinals: Where do you stand?
|
on: February 17, 2023, 12:51:40 PM
|
... if you have some info about someone who is trying to insert such data in the blockchain (i.e. IP adresses) then you should be safe.
imagine some fool uploading illegal porno to ordinals that doesn't use a fake ip.  But miner wouldn't know personal information of that fool unless he/she contact miners directly (e.g. send email to miner from gmail). In most cases, miner only can obtain IP address of node which re-broadcast that transaction. Im really concerned about child pornography, lets say some ones daughter being raped and murdered ending up on Bitcoin. Or racism or something that would make a nation say absolutely no to Bitcoin. Take the story of the Tank man on Tiananmen in China, Gov secrets. That will not be accepted when they see that this network will spread truth.
Unfortunately all of the already happen far before Ordinal exist. See these article, https://www.newsweek.com/bitcoins-blockchain-contains-child-abuse-images-dark-web-links-and-wikileaks-857335https://www.righto.com/2014/02/ascii-bernanke-wikileaks-photographs.html#ref14Bitcoin should be good at one thing and one thing only.
I agree. But on technical level it's impossible to ensure Bitcoin only can be used as currency/payment method while remain decentralized/permissionless. |
|
|
|
|
1139
|
Bitcoin / Project Development / Re: Let's build a competitor to OrdinalsBot.com
|
on: February 17, 2023, 12:35:09 PM
|
--snip--
Dont really use this much so feel free to dm on telegram if you wanna partner?
I believe you forget to mention your telegram username on this thread. Hey guys, so i’m considering starting my own competitor to OrdinalBots.com
Obviously, OrdinalBots.com is no longer any competition. the domain is for sale and an auction is open for receiving bids for the purchase of that domain. Maybe you should think about buying it because it will save you a lot of money for marketing and promotion from a well-known service rather than the beginning. although as far as I have seen the basic metrics, that domain did not have any significant traffic, so it is questionable how much real profit the service made on it.  OP actually refer to ordinal sbot.com, not ordinalbot.com. OP mention correct domain on title, but mention wrong one on content section. |
|
|
|
|
Show Posts
