 Show Posts
|
|
Pages: [1] 2 »
|
Do you want to know how to make this possible with this very router? Yes, I guess that would be the most convenient way if it is possible for this router. Or maybe buying another router is an option, but then I have to make sure it has SIM card support and port forwarding. How about allowing incoming connections in another way? I also thought about using my VPS as a proxy, so my node could initiate a connection with my VPS, and that server would connect with the rest of the world. Of course, in this case the easiest way would be just running a full node on my VPS directly, but as I want a full node and I don't have 400 GB disk on my VPS, I thought about just routing the network traffic through my server. Using Tor may solve my problem partially, I will try to set up that, but I am still looking for a way to do that also for clearnet connections. |
|
|
|
I find it hard to believe there are two independent people who are posting with this many spelling errors on each of these threads. I guess they are independent people, because by checking their posting history from local boards you can conclude that COBRAS is from Russia and interiawp is from Poland (in this case even the word "interia" suggests it, because there is a page https://www.interia.pl/ that is quite popular in Poland). Do you have any idea why they are talking with so many spelling errors? I don't know, but reading all of these words in WanderingPhilospher's post with replaced "i" and "y" was quite funny. COBRAS YOU ARE DEBIL! That was funny, because as far as I know, there is no such word in English. But I guess it has almost the same meaning in Polish and Russian: https://www.urbandictionary.com/define.php?term=Debilthat it is not even clear what his requirements are For me, the whole topic sounds like a joke and I have no idea how to make it useful. |
|
|
|
I can reproduce the same error messages in 22.0 Yes, it was the newest official release 22.0 for Windows. |
|
|
|
It seems that Bitcoin Core is affected by 2038 year problem, I set my clock to 0x7fffffff and the client is halted with this assertion, because when reaching 0x80000000 it is treated as a negative value. ---------------------------
Microsoft Visual C++ Runtime Library
---------------------------
Assertion failed!
Program: C:\Program Files\Bitcoin\bitcoin-qt.exe
File: util/time.cpp
Line: 97
Expression: now.count() > 0
For information on how your program can cause an assertion
failure, see the Visual C++ documentation on asserts
(Press Retry to debug the application - JIT must be enabled)
---------------------------
Abort Retry Ignore
--------------------------- Edit: It seems that I was right and when median time will reach 0xffffffff, it will be impossible to create any new blocks in such chain. Then, modifying the chain is no longer possible without chain reorganization, because the timestamp of the next block has to be greater than 0xffffffff, so there is no 32-bit value that can meet this rule. submitblock 0100000006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910f3663c0de115e2239e05df4df9c4bfa01b8e843aaf5dae590cac1d9bac0d44c0fffffffffffff7f200100000001020000000001010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0200f2052a010000001976a91462e907b15cbf27d5425399ebf6f0fb50ebb88f1888ac0000000000000000266a24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf90120000000000000000000000000000000000000000000000000000000000000000000000000
null
generatetoaddress 1 mpXwg4jMtRhuSpVq4xS3HFHmCmWp9NyGKt
CreateNewBlock: TestBlockValidity failed: time-too-old, block's timestamp is too early (code -1) |
|
|
|
|
I tested some values by starting from zero unix time and saw that it always can only go forward, because it always has to be greater than the median time of the last 11 blocks. But I have another time-related question: will the chain be halted when reaching median time equal to 0xffffffff? Or maybe we have some kind of overflow bug here, as it was in Value Overflow Incident, but time-related, so is it possible to jump back from 0xffffffff to 0x00000000?
|
|
|
|
At this point it's probably not even possible to ever reach supermajority for a hard fork increase thus proving Bitcoin is in fact decentralized. Perhaps the only thing that would get everyone on board was a global ban on physical cash, then the only way out for financial privacy would be Bitcoin, at this point it would be an organic demand for a block space and maybe there would be supermajority reached. Even in that case, creating an " evil" soft fork could still be better than hard fork. But I guess that something like an extension block could be a better solution, because then you have to/from transactions on-chain and everything else can happen inside this additional block, that can be visible only by upgraded clients and can be for example 1 GB in size if needed. |
|
|
|
Why does it matter? Because if doing so is possible, then another kind of attack is possible. For example: an adversary miner could start producing blocks with future timestamps to drop difficulty, then jump back in time (if it is possible and if that does not require dealing with endlessly growing difficulty), and then create a deep reorganization, because a lot of blocks with smaller difficulty could create a sum of chainwork greater than the honest chain. That attack could be of course noticed by anyone, but if it matches consensus rules, then it will be accepted by existing clients. Also, there are some altcoins with different difficulty adjustment algorithms, if the same way of checking time is repeated in other coins, then that altcoins could be potentially easier attacked in this way, because their difficulty can be changed sooner than for example every two weeks. Edit: Because of NLockTime. (Going to continue, gotta go) Imagine that some transaction have NLockTime set in October 2021. Does it mean that if such transaction is included in the chain, then it is impossible to create any next block with any timestamp below that NLockTime? How it is checked? If you have a new block header, is it compared with some globally stored max(NLockTimeTx1,NLockTimeTx2,...,NLockTimeTxN)? |
|
|
|
|
Is it possible to go back in time in a chain? For example, starting from 2009 is it possible to produce blocks with earlier and earlier timestamps and for example reach 2005? Or is there any strict requirement that block timestamps have to go forward? Because if there are three sources of time: local time, time from other nodes and time from block headers, if the first two will be faked, is it possible to also fake block timestamps and set any date, if the whole chain will be long enough?
|
|
|
|
I recently read topic https://bitcointalk.org/index.php?topic=382374.0 and I wonder how exactly that prenet genesis transaction looked like. After some digging I came up with this: decoderawtransaction 01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff0504695dbf0effffffff01102700000000000044ab4104d451b0d7e567c615719a630b9f44632a0f34f5e7101f9942fe0b39996151cef10a809c443df2fab7cd7e58a3538cd8afd08ccfaa49b637de4b1b383f088ad131ac00000000
{
"txid": "25c61a7089aa96318088bcccfbc12064a18166105c20c237836704611254d2da",
"hash": "25c61a7089aa96318088bcccfbc12064a18166105c20c237836704611254d2da",
"version": 1,
"size": 133,
"vsize": 133,
"weight": 532,
"locktime": 0,
"vin": [
{
"coinbase": "04695dbf0e",
"sequence": 4294967295
}
],
"vout": [
{
"value": 0.00010000,
"n": 0,
"scriptPubKey": {
"asm": "OP_CODESEPARATOR 04d451b0d7e567c615719a630b9f44632a0f34f5e7101f9942fe0b39996151cef10a809c443df2fab7cd7e58a3538cd8afd08ccfaa49b637de4b1b383f088ad131 OP_CHECKSIG",
"hex": "ab4104d451b0d7e567c615719a630b9f44632a0f34f5e7101f9942fe0b39996151cef10a809c443df2fab7cd7e58a3538cd8afd08ccfaa49b637de4b1b383f088ad131ac",
"type": "nonstandard"
}
}
]
} Of course I know that transaction version was not present here (in the same way as in the block hash there was no version) and I can calculate sha256 of any data, but still, that transaction should hash into 769a5e93fac273fd825da42d39ead975b5d712b2d50953f35a4fdebdec8083e3. I tried using different values for OP_CODESEPARATOR and OP_CHECKSIG than 0xab and 0xac, but still no match. I tried different endianness in 32-bit and 256-bit values, but still no luck. The only success so far was hashing the prenet genesis block: prenetGenesis=0000000000000000000000000000000000000000000000000000000000000000e38380ecbdde4f5af35309d5b212d7b575d9ea392da45d82fd73c2fa935e9a76a00bc84814000000bb290200
prenetGenesisHash=7ae24cfad8adbe66ab2224a4f7269694fa2fa9aa157b1e44c608bd386fb6160b
prenetGenesisDoubleHash=46a6fa0cbc6e41aaebb6916c55013a0ad66b11e91d1d977ed627135db1060000
prenetGenesisFinalHash=000006b15d1327d67e971d1de9116bd60a3a01556c91b6ebaa416ebc0cfaa646 Is that lost in the past or is it possible to reconstruct that transaction as it was in prenet? |
|
|
|
If you want to write a script for hash collision you usually want to use the same hash algorithms not 2 different ones (SHA1 and HASH160). Collision is already taken, I think about preimage. HASH160 is used to set target for that preimage, in this way it would be impossible for miners to steal that coins from the winner, because only the author of the solution will know the private key. Also the second OP_2DUP needs to be OP_SWAP so that you "swap" the 2 stack items and hash the other item. Without duplication, that public key would be lost during hashing, so using OP_CHECKSIG later would always evaluate to false. There is also no need for a OP_CheckSig in a hash collision script. Without it, any miner could steal coins from the winner. This is not a collision, this is preimage. Something like "OP_SHA1 <160-bit zero value> OP_EQUAL" would also work, but in this way any miner could take that coins. Here, instead of some predefined value, you can take your public key, hash it, and then try to create preimage using any message that hashes to this value. the first part where it checks that something != pubkey is useless since SHA1 is not the same as HASH160 Good point, so the first four opcodes can be skipped: decodescript a76e75a988ac
{
"asm": "OP_SHA1 OP_2DUP OP_DROP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG",
"type": "nonstandard",
"p2sh": "2MvtHZjt8oeLFv21TmmpaEy79ZXJa1D5Eke",
"segwit": {
"asm": "0 c41cd68d0bc660607174343ab0f31638f7977faaab3c3022b1fcebd76dda6fd9",
"hex": "0020c41cd68d0bc660607174343ab0f31638f7977faaab3c3022b1fcebd76dda6fd9",
"reqSigs": 1,
"type": "witness_v0_scripthash",
"addresses": [
"tb1qcswddrgtcesxqut5xsatpuck8rmewla24v7rqg43ln4awmw6dlvsnphpn6"
],
"p2sh-segwit": "2NBQZBHBPNuhNDwCPoZP1cetPcEany2GBhR"
}
} [signature][publicKey][sha1image] //OP_SHA1
[signature][publicKey][sha1(sha1image)] //OP_2DUP
[signature][publicKey][sha1(sha1image)][publicKey][sha1(sha1image)] //OP_DROP
[signature][publicKey][sha1(sha1image)][publicKey] //OP_HASH160
[signature][publicKey][sha1(sha1image)][hash160(publicKey)] //OP_EQUALVERIFY
[signature][publicKey] //OP_CHECKSIG
[1] |
|
|
|
decodescript 6e879169a76e75a988ac
{
"asm": "OP_2DUP OP_EQUAL OP_NOT OP_VERIFY OP_SHA1 OP_2DUP OP_DROP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG",
"type": "nonstandard",
"p2sh": "2NE2dLCZzw7nYSKaHouiSjKWHry9qXgcJyt",
"segwit": {
"asm": "0 b91d7ae4c9fc1edca8d16a679b2843560f50eeb78db6aa051c62d6d5b73f2013",
"hex": "0020b91d7ae4c9fc1edca8d16a679b2843560f50eeb78db6aa051c62d6d5b73f2013",
"reqSigs": 1,
"type": "witness_v0_scripthash",
"addresses": [
"tb1qhywh4exfls0de2x3dfnek2zr2c84pm4h3km25pguvttdtdelyqfsqnquhy"
],
"p2sh-segwit": "2NCdayxXk2GNnz3xFCDoQcdNgQFWhgh5qwP"
}
} [signature][publicKey][sha1image] //OP_2DUP
[signature][publicKey][sha1image][publicKey][sha1image] //OP_EQUAL
[signature][publicKey][sha1image][0] //OP_NOT
[signature][publicKey][sha1image][1] //OP_VERIFY
[signature][publicKey][sha1image] //OP_SHA1
[signature][publicKey][sha1(sha1image)] //OP_2DUP
[signature][publicKey][sha1(sha1image)][publicKey][sha1(sha1image)] //OP_DROP
[signature][publicKey][sha1(sha1image)][publicKey] //OP_HASH160
[signature][publicKey][sha1(sha1image)][hash160(publicKey)] //OP_EQUALVERIFY
[signature][publicKey] //OP_CHECKSIG
[1] |
|
|
|
|
Classical mining is based on finding the smallest possible block hash. But as we know, r value of the signature can be smaller than usual if it starts with some zeros. Leaving half of the base point behind, I can imagine a system where miners collect transactions and try to find some value that can be added to "r" and can lead to smaller signatures. Users can receive such values in P2P way, because each miner can just share his "r2" public key to prove that miner found the lowest public key for that signature. Then, that user can send some satoshis in LN as a reward to that miner, and to unlock that coins, the miner have to reveal that private key for "r2" to the user. Then, that user can create smaller signature, leaving more room for other transactions in the blockchain.
Assuming one satoshi per byte fee rate and 2,000 transactions in the whole block, saving 5 bytes per transaction would mean earning 10k satoshi per block (and leaving some room for 40 more transactions 250 bytes each). Of course it is negligible for big miners, but for smaller ones it may be profitable, if they could fight for some satoshis. And the profitability limit will be quite high, because truncating five or six bytes may be profitable, but hitting eight or more will be exponentially more difficult, so it rather encourage hitting more transactions than more zeroes in single transaction.
It can be applied to any address type that involves public keys, including multisig and Segwit, because transaction fees are based on total transaction size. So, even if Segwit signatures are outside of the block, users can still pay less satoshis for including such transactions with "mined r values". Unfortunately, that kind of service cannot be applied for taproot, because that signatures has fixed size of 64 bytes, but they are compressed to single signatures anyway, so there is less need for that kind of compression.
|
|
|
|
|
Recently I found an interesting testnet transaction: 952656e19ce57698880ad6ada935f29ee2cae82c4e7486516908b630671dd84b. It seems to be some kind of puzzle, but probably even the author cannot just move the coins without actually solving it (which is not the case in well-known mainnet transaction 08389f34c98c606322740c0be6a7125d9860bb8d5cb182c02f98461e5fa6cd15). So, if I understand it correctly, the goal is to create any address with as low 160-bit hash as possible and then take these coins. I guess it is on testnet, because of the standardness limits on mainnet. The whole change seems to be quite simple, instead of "OP_EQUALVERIFY" there is "OP_LESSTHAN OP_VERIFY".
|
|
|
|
|
For now, we have public key hashes as outputs and then it is needed to reveal public key and signature in inputs. But the properties of ECDSA allows us to skip this public key and by having some address and some signature, it is possible to verify it (in exactly the same way as we can type some address and signature and verify any message, not necessary being a transaction). Then, why storing public keys in the blockchain is needed if they can be safely skipped and calculated from signature and address?
|
|
|
|
|
It is impossible. For example, let's assume that k1=2, k2=3. Then, if you take Q=GenesisPubKey, you would have:
2*halfGenesisPubKey=GenesisPubKey
3*oneThirdOfGenesisPubKey=GenesisPubKey
genesisPrivKey*G=GenesisPubKey
Finding "genesisPrivKey" is impossible in this case, the same for any other public key. If it would be possible, then ECDSA would be gone instantly.
|
|
|
|
|
Instead of sending coins to "OP_DUP OP_HASH160 <hash> OP_EQUALVERIFY OP_CHECKSIG" I sent them to "OP_HASH160 <hash> OP_EQUAL". Both hashes are exactly the same. Are they burned or is it possible to get them by using some kind of non-standard transaction?
|
|
|
|
And how are they going to securely send the customer the seed and public key to the multisig wallet without it getting intercepted by an attacker? Someone getting possession of it will neutralize the security of using multisig in your plan. Are you trying to say that sending public keys over HTTPS is not secure somehow? Also, intercepting public keys could only harm privacy, but still, private keys are needed to spend it. Also, multiplying and dividing keys is enough to prove the ownership of some private key and share the public key at the same time. More than that: both private keys are needed (or both signatures signing some transaction chosen by the attacker). If only one would be compromised, then altering transaction by some third party is impossible. unless you are mining at a pool, but then there's some form of centralization here, they can almost be considered a "cloud" too Exactly. It could be useful to receive some smaller amounts by forming some kind of CPU pool. For example: if mining 1 BTC needs a lot of power, then mining single satoshi is 10^8 times easier. Then, if there are many clients, that could be promising somehow. "Cloud" or "pool" mining operator can just receive shares and send payments in this "LN-like way". Sooner or later, millions of such miners could produce a block. |
|
|
|
|
For now, there are many services that offer cloud mining. The scheme used here is as follows: at first, you deposit coins to some website and then they are showing you some growing numbers. You can withdraw funds after reaching some value, you can also stick with some free plan or purchase some paid option, that will speed up your mining, depending on this item's price.
The problem with this type of sites is that most of them are just scams, you can deposit some coins, you can even withdraw them for a few months, but then, suddenly the whole website can disappear and reappear under completely new address.
It seems that blockchain also provide solution for this type of service. Instead of depositing coins to some cloud mining address, you can send them to some 2-of-2 multisig. Then, they can make sure that funds are really deposited, but at the same time you can make sure they just don't run away with your coins. And then, they can show you some growing numbers, allowing also some purchases of mining equipment or withdrawing coins.
If you decide to withdraw some of them, you can just create a new transaction spending coins from the multisig input and all they have to do is just signing it. More than that: if they want to gain your trust and show a good will, they can periodically create a transaction that allow you to withdraw all already mined coins and they can sign it.
|
|
|
|
Suppose we have support in bitcoin (and for swap purposes in another coin, Xcoin) scripting language for a secure hash function H which is homomorphic in the sense that:
H(a) + H(b) = H(a+b) //---> homomorphism No hash function is needed here. ECDSA private and public keys can be used instead. So, "a" and "b" could be just private keys, and "H(x)" could mean the public key created from the private key "x". Are there any security problems with that replacement? Edit: Now for Bob to claim his bitcoins he needs to reveal the secret b, letting alice to compute a+b and use it as the secret necessary for claiming her Xcoins. Here, in case of public keys, multiplication may be better, because then without having "a" or "b" you don't even know that "a*b" is not some random key. And then, all that is needed is just sending coins to (a*b)*G, then someone with access to both private keys will be able to move the coins. But then, the question is: how this design is better than just 2-of-2 multisig? Especially when we also use Schnorr signatures and taproot here? |
|
|
|
|
