 Show Posts
|
|
Pages: « 1 [2] 3 4 »
|
So do you know how many of Japanese versions of XP were sold during 2005 and 2007? Because he had started working on the project 2 years before the release. You don't have to guess "2005 and 2007", or anything like that. If you try to grep the source code of 0.01 version, you will find some places, where "2007" is explicitly revealed, and even the more precise date is present. For example, if you check "sha.h", you will find 24th September 2007: // This file is public domain
// SHA routines extracted as a standalone file from:
// Crypto++: a C++ Class Library of Cryptographic Schemes
// Version 5.5.2 (9/24/2007)
// http://www.cryptopp.com
#ifndef CRYPTOPP_SHA_H
#define CRYPTOPP_SHA_H
#include <stdlib.h> This is the earliest date I found, but maybe after more digging you could find something at the beginning of September 2007. But I doubt there are any earlier timestamps anywhere. Also, from the code structure itself, you can easily deduce, that importing hash functions like SHA-1, was done by Satoshi in 2007, and then he stopped upgrading libraries. His strategy was quite simple: you need a library? So, get the latest version, install it here and now, and then forget about upgrading, if everything works correctly. Another thing you should also do, is to go through the whitepaper, scroll down to the "References" paragraph, and grab all of those documents one-by-one. Then, you will note, that "hashcash" is the sixth position, but it is also "the third from the bottom". If you use reversed order, then you note that in many lists, Satoshi actually used reversed order. For example, he listed "Visual C++" first, and then added "MinGW" at the first position. The same with other references. Which is quite interesting, because it means, he didn't start from some "Abstract" or "Introduction", but the first paragraph was probably called "Calculations", and he wrote a lot of code, to confirm everything he read in 8th reference about "probability theory and its applications", then created a system based only on public keys alone, without any hashing, using "Protocols for public key cryptosystems", and then jumped into "Hashcash", and downloaded SHA-1 library as a dependency on 24th September 2007, and didn't upgrade it since then (also because later SHA-1 was replaced by SHA-256). Knowing the type of RNG used in that period is also good There are some topics on bitcointalk, where you can get more details: https://bitcointalk.org/index.php?topic=113496another thing, he used a single core CPU, that's why he later added multiproccessor support for mining Yes, but he added those things to his own miners first, and then publicly released them. Which means, he didn't release it from the first day, when he heard about such possibilities. There are many proofs to support that fact. First: he mined 40-bit Genesis Block, and initially planned 40-bit difficulty for mainnet, and 20-bit difficulty for testnet (see November 2008 source code for more details). Second: if you have any multi-threaded program, then it is harder to do that correctly. It is far easier to run N instances of console application, and let your Operating System do the thing, than implement it in C++ in 2009 (maybe also in assembly). Third: he was against GPU arms race, and tried to postpone it for as long as possible, to encourage more people, by offering them the possibility to mine on their CPUs. he said, he thought Satoshi was some Japanese guy He definitely was. Maybe I should be more clear here: I don't think Satoshi is Hal. But I think Satoshi is from Japan. Because I heard some people saying "he is obviously not some Japanese guy". And then I found more than enough proofs, that his whole Operating System had Japanese language enabled. Also, if you want to deduce, that he used Windows XP, and not for example Windows 98, then you can read, what he thought about using some older version of the Bitcoin client, and also read all things, when he mentioned about Windows Vista as "Vista hasn't been tested yet". That word "yet" means, he would also do that, if possible. |
|
|
|
he said, he thought Satoshi was some Japanese guy He definitely was. I have many confirmations for that fact. First, start from "readme.txt" in "BitCoin v0.01 ALPHA" (yes, that 0.01 version is present here, which is also significant, and explains, why the magic number 100 is used as a version number separator). But in the "src" folder, there is another "readme.txt", and you can read there: Compilers Supported
-------------------
MinGW GCC (v3.4.5)
Microsoft Visual C++ 6.0 SP6 That second compiler was most likely used by Satoshi, because there were "std::min" and "std::max" issues in the source code, that were specific to "Visual C++" compiler. And, guess what, if you try to find that compiler, you will find this one: https://archive.org/details/microsoft-visual-c-6.0-standard-editionThen, guess what: installing it on a non-Japanese Windows XP is a disaster, and ends up with displaying all of those characters as "?". Also, it explains "„" character, that was present in paths, instead of slashes/backslashes. If you don't believe me, then try to find another "Microsoft Visual C++ 6.0 SP6" version anywhere: you will notice, that this Japanese version is the most popular one. And if you want to use it, you need a Japanese version of Windows, because in other cases, the whole installation process will be very painful. Also, if you try to run "BitCoin" client on Windows XP, you will notice a lot of things. For example, that running more than one instance of "0.01" version is not that easy, as you could expect, because the port 8333 will be already used by the first instance, and the whole traffic management requires activating another "main" function, and some other changes like that, or some weird stuff like "port forwarding". Also, by exploring more things, you can note that Windows XP with Japanese language version, was used on his physical machine, and no VirtualBox or other virtualization tool was there. But, first things first, installing the same compiler as Satoshi, the same tool for PDF as Satoshi, and other things like that, should give you enough proofs to start with. And if you need a proof that Satoshi really used those things, then explore file metadata, and note that if you want to fake everything, it is extremely painful to do that correctly, and it is then easier to just use the real tools without tampering with the data. |
|
|
|
You can't just give an array of numbers and expect us to find patterns. Exactly, random in, random out. You can try to be lucky and check OEIS, but if you expect a random response, then here you are: https://bitcointalk.org/index.php?topic=5407344.0I need it to my test which I implement my own trained AI. Try to ask any AI about things like block hashes, transaction hashes, or any kind of math, like multiplying some 32-bit number by itself. You would be surprised, how random will your results be. |
|
|
|
This does not really create tail emission though, it creates temporary tail emission where part of the mining rewards have to be delayed so that they are received at a later block far past the year 2140. It is no longer possible to do once the block reward is completely exhausted. There are many solutions to that: 1. Forced Soft Forks: https://petertodd.org/2016/forced-soft-forksSo what is a valid Bitcoin 2.0 block? It could be anything at all! For example, the inflation schedule can be changed to make the coin supply unlimited. 2. Changing coin ownership, without touching 21 million coin limit: from the economical point of view, it is equivalent: Imagine there are 21 million coins, distributed to many different users, and the block reward is zero. Then, imagine that 21 million coins are produced, because of tail emission. Then, you can have two systems:
1) with fixed supply, where everyone will lose half coins in explicit way, and they will be taken by miners, because of tail emission: 10.5 million coins will remain in users' hands, 10.5 million coins will be taken by miners, 21 million coin limit is untouched
2) with infinite supply, users will have exactly the same amounts, but they will be worth 50% less than before, because miners will be always rewarded by new coins, because of tail emission 3. Introducing zero satoshis, and treating them as non-zero amounts: So, you know what is needed: zero satoshis. Then, it is possible to create some additional outputs, send zero satoshis there, and use "<anyStandardScript> <newAmount> OP_DROP" as an output script (or this "<newAmount> OP_DROP" could also be placed inside witness script, or as an input, many things are possible). It could be handled in the same way as Segwit vs NonSegwit: if it was possible to create a situation, where old nodes cannot see new signatures, then it is also possible to create a situation, where old nodes will not see new amounts (there could be many reasons, for example if hiding amounts will ever be introduced, then it is reasonable to put zero for backward compatibility, but the same solution can be used to introduce any coins to the system, because the size of the UTXO set is not limited). And then, it is all about human factor: if those zero satoshis will be really used to move real values, then they could be traded, bought, sold, and used in real life. If it is possible to create NFTs out of thin air and sell them for millions, then why producing coins out of thin air and selling them for real goods and services wouldn't work as well? 4. Something else. There were many ideas, just read the whole topic about tail emission: https://bitcointalk.org/index.php?topic=5405755.0They cannot verify the post-softfork transactions. If you make it explicit, by taking single satoshis from users, instead of producing new coins, you will reach identical economy, while preserving backward compatibility. |
|
|
|
And the questions is why the result is nocne = 0 Well, I explored it further, and it seems that you are trying to add two points that will sum to zero. r= 0x8b2f34a1cc88961f21f7bf26c20d57e822ae785d9e8e43a22c8fdf59bcc90fa9
s= 0xcf641f21b891e22aa4e0238dfca22049476e6d7ec88d280c0ba2397d0ff0897a
z= 0x5d19b32a41b52787a825aeb35d26bd243becac82d1a260cd2102ddd592f80a28
priv= 0x864480801d0c1559f2d18e00304cad8a3982d5e552a62ae3e09ccb4974546570
pub= 04 AD36FAD55727EBF76F8AF96C7C2DF9A298DC21D6C15269FDEDFD47A70B327637 906D883CAD59E70568EA67ABE388A621A76F1056DD34A9E309A314DB8C61EF79
verify(r,s,z,pub)
w= 0x149e7f7624151ac888da9006b5c2af5ac1d08dc25dc1723b060b38215f8e66e4
u1= 0xe53e7009a7a991c1725d610e5680224072c3155d60b2a3addd8725ce6ccffe23
u2= 0xcb4915881038c93270b7c8dca61a4051e799e8f9d560e69f32de5cf09a6beca2
u1*G= 04 4C02C3B02A8FC5DC621977E67D084EEE45B9571197BAF102E680F068ECC15E15 487B4FC7E0FC6FF09C0E893CB69AE85A2275388948AA8C711B5D8924ECD19664
u2*public_key=04 4C02C3B02A8FC5DC621977E67D084EEE45B9571197BAF102E680F068ECC15E15 B784B0381F03900F63F176C3496517A5DD8AC776B755738EE4A276DA132E65CB
D= 04 0000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000 Why it is the case? Well, because (r,s) is as valid as a signature, as (r,-s). Which means, if you have r-value, you have those two options: r= 0x8b2f34a1cc88961f21f7bf26c20d57e822ae785d9e8e43a22c8fdf59bcc90fa9
R1=04 8B2F34A1CC88961F21F7BF26C20D57E822AE785D9E8E43A22C8FDF59BCC90FA9 BBA72B3BD19EABC7E102B40F944C7C5C834A092D5EEE60211729F622246CB70A
R2=04 8B2F34A1CC88961F21F7BF26C20D57E822AE785D9E8E43A22C8FDF59BCC90FA9 4458D4C42E6154381EFD4BF06BB383A37CB5F6D2A1119FDEE8D609DCDB934525 And you cannot take only R1 or only R2. Your solution should be resistant to that. |
|
|
|
the question was why the point is 0:1:0 as nonce for those privatekey Because you reached zero, and tried to apply inverse on that. ZeroDivisionError: inverse of Mod(0, 115792089237316195423570985008687907853269984665640564039457584007908834671663) does not exist And why you reached zero? I guess because you picked a single signature again, and tried to attack it. And then, you reached two different signatures, that were created from the same source, so you still have a single signature, but you assume you have two of them. So, probably you are still trying to find a hole in ECDSA in some place, where there is none. Because you will never have for example z=0. If you would, that would mean your hash function is totally broken. Also, for z=0, finding a matching ECDSA signature is trivial, but that kind of attack is useless, as long as you cannot break SHA-256. in sage -> run as sage Note it can also run Python as well, if you pick it from the dropdown list. |
|
|
|
Just use Sage Cell Server, and pick "Python" instead of "Sage", then it will point you directly to all errors: (0 : 1 : 0)
---------------------------------------------------------------------------
ZeroDivisionError Traceback (most recent call last)
Cell In [1], line 1
----> 1 exec("""p = 0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f
2 n = 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141
3
4 E = EllipticCurve(GF(p), [0, 7])
5
6 G = E.point( (0x79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798,0x483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8)) # Base point
7
8 def egcd(a, b):
9
10 if a == 0:
11
12 return (b, 0, 1)
13
14 else:
15
16 g, y, x = egcd(b % a, a)
17
18 return (g, x - (b // a) * y, y)
19 def modinv(a, m):
20
21 g, x, y = egcd(a, m)
22
23 if g != 1:
24
25 raise Exception('modular inverse does not exist')
26
27 else:
28
29 return x % m
30
31 def verify(r, s,z,public_key):
32 w = int(modinv(s, n))
33 u1 = int((z * w) % n)
34 u2 = int((r * w) % n)
35 D=u1*G + u2*public_key
36 print(D)
37 x,y=D.xy()
38 x=int(x)
39
40 if (r % n) == (x % n):
41 print( \"signature matches\")
42 return 1
43 else:
44 print(\"invalid signature\",r,x%n,hex(int(x%n)))
45 return -1
46
47
48 r= 62954891018019954459416693598720448029687590245972400008829669497225918091177
49 s= 93805659226466445992581382639747054957343960360429636701520966540504046012794
50 z= 42110502646696890819993970892170079655178794598857292674837771894242690992680
51 priv= 60730954188027216046258787068258904013610447813898304297373912116496774227312
52
53 pub=priv*G
54 print(verify(r,s,z,pub))
55 """)
File <string>:54
File <string>:37, in verify(r, s, z, public_key)
File /home/sc_serv/sage/src/sage/schemes/elliptic_curves/ell_point.py:776, in EllipticCurvePoint_field.xy(self)
774 return self[0], self[1]
775 else:
--> 776 return self[0]/self[2], self[1]/self[2]
File /home/sc_serv/sage/src/sage/structure/element.pyx:1730, in sage.structure.element.Element.__truediv__()
1728 cdef int cl = classify_elements(left, right)
1729 if HAVE_SAME_PARENT(cl):
-> 1730 return (<Element>left)._div_(right)
1731 if BOTH_ARE_ELEMENT(cl):
1732 return coercion_model.bin_op(left, right, truediv)
File /home/sc_serv/sage/src/sage/rings/finite_rings/integer_mod.pyx:2248, in sage.rings.finite_rings.integer_mod.IntegerMod_gmp._div_()
2246 71428571429
2247 """
-> 2248 return self._mul_(~right)
2249
2250 def __int__(self):
File /home/sc_serv/sage/src/sage/rings/finite_rings/integer_mod.pyx:2334, in sage.rings.finite_rings.integer_mod.IntegerMod_gmp.__invert__()
2332 """
2333 if self.is_zero():
-> 2334 raise ZeroDivisionError(f"inverse of Mod(0, {self.__modulus.sageInteger}) does not exist")
2335
2336 cdef IntegerMod_gmp x
ZeroDivisionError: inverse of Mod(0, 115792089237316195423570985008687907853269984665640564039457584007908834671663) does not exist |
|
|
|
So may there be the possibltly that some kind of extra reward can be send by the Algo to the miners by Scrypt or anything else with only a soft fork? Yes, and it was well-explained in this topic: https://bitcointalk.org/index.php?topic=5405755.0Please technical informative replies only! There were many technical examples, for example this one: Is it desirable, much less moral, for a percentage of the world's wealth to be in the hands of some early whales? Imagine a system, where in every block, every miner could get one satoshi per 0.01 BTC on that address. In fact, there is no difference between a system with tail supply, and a system with fixed supply, where you can take someone's coins. Because that's what inflation is about: proportions. That's the only thing that matters. So, no hard forks are really needed to create a tail supply, you can instead force all users to pay a "tail supply fee", for example one satoshi per each 0.01 BTC. Then, miners could be forced by a soft-fork, to lock those "tail supply fees" to some future block number, just by using OP_CHECKLOCKTIMEVERIFY, to increase future block rewards. And because it is something that can be solved by changing fee policy, no forks are needed to introduce that. How would that even work technically? Coins whose keys have been lost cannot be moved... You can always create a timelocked transaction, that could be mined after block number N. And then, you can publish it, then there are two options: 1) you will move your coins before block N, so the broadcasted version will be invalid 2) you will lose your keys, so after block N, miners will pick it (miners, if it will require no keys, but you can of course decide, what conditions are needed to take it) |
|
|
|
Cóż, Saint Wenhao mi się kiedyś trafił podczas żeglowania po freenecie. |
|
|
|
As I envision it, each Bitcoin address could issue claims on its value simply by signing a claim with its private key. Yes, you can always do that. You can use Bitcoin Message, or you can sign things in the signet way, by signing a transaction that is invalid on the main network, using BIP-322. Claims could have restrictions on who could claim it, under what conditions, etc. (Much of this machinery already exists in Bitcoin's script language, if I understand correctly.) Exactly. For that reason, Bitcoin Message is not enough, and you should have an ability to sign any scripts. You can do that by signing transactions, that would be valid only in your network. Of course, this is essentially what the Lightning Network does. Yes, you could get a sidechain-like system, just by collecting Lightning Network transactions, and putting them on your own chain. Then, some problems are solved, for example then you don't need any watchtower, and you can batch transactions, by observing the network, and by signing cut-through transactions, simplifying A->B->C on-chain chains into A->C transactions, when all parties agree, and when all penalty transactions are prepared (and automatically unlocked, if any old state will be broadcasted, so all honest nodes will act as a one huge watchtower, active 24/7). If there are insufficient funds, the transfer does not occur, and the failed claim remains on the blockchain as a blackmark on the address's record. Yes, there are many options. You can release a penalty transaction, or you can just blacklist some output in a publicly known way, by sending some signed transaction to everyone as a proof that something bad happened. It is up to you, how you will handle cheating in your network. |
|
|
|
Why this value can be rotated like in a clock? 1dba45ae684199cd23ab3f4de753d962f7a4e79060df26e4ed19c677b4a37800^1=1dba45ae684199cd23ab3f4de753d962f7a4e79060df26e4ed19c677b4a37800
1dba45ae684199cd23ab3f4de753d962f7a4e79060df26e4ed19c677b4a37800^2=ac9c52b33fa3cf1f5ad9e3fd77ed9ba4a880b9fc8ec739c2e0cfc810b51283cf
1dba45ae684199cd23ab3f4de753d962f7a4e79060df26e4ed19c677b4a37800^3=70ad49ae7f8574ecab641a42b3a24f22d6374023944cc665a6bcaeb0f37bbf78
1dba45ae684199cd23ab3f4de753d962f7a4e79060df26e4ed19c677b4a37800^4=ac9c52b33fa3cf1f5ad9e3fd77ed9ba4a880b9fc8ec739c2e0cfc810b51283ce
1dba45ae684199cd23ab3f4de753d962f7a4e79060df26e4ed19c677b4a37800^5=52f304001743db1f87b8daf4cc4e75bfde925893336d9f80b9a2e8393ed84778
1dba45ae684199cd23ab3f4de753d962f7a4e79060df26e4ed19c677b4a37800^6=fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364140
1dba45ae684199cd23ab3f4de753d962f7a4e79060df26e4ed19c677b4a37800^7=e245ba5197be6632dc54c0b218ac269bc309f5564e697956d2b898151b92c941
1dba45ae684199cd23ab3f4de753d962f7a4e79060df26e4ed19c677b4a37800^8=5363ad4cc05c30e0a5261c028812645a122e22ea20816678df02967c1b23bd72
1dba45ae684199cd23ab3f4de753d962f7a4e79060df26e4ed19c677b4a37800^9=8f52b651807a8b13549be5bd4c5db0dbe4779cc31afbd9d61915afdbdcba81c9
1dba45ae684199cd23ab3f4de753d962f7a4e79060df26e4ed19c677b4a37800^a=5363ad4cc05c30e0a5261c028812645a122e22ea20816678df02967c1b23bd73
1dba45ae684199cd23ab3f4de753d962f7a4e79060df26e4ed19c677b4a37800^b=ad0cfbffe8bc24e07847250b33b18a3edc1c84537bdb00bb062f7653915df9c9
1dba45ae684199cd23ab3f4de753d962f7a4e79060df26e4ed19c677b4a37800^c=0000000000000000000000000000000000000000000000000000000000000001 Are there other such values? How to get them? Is it possible to reach them for some other value like 2 or 3, for example to get it in five moves or in seven moves? Also, it is true for "n=fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141", is it possible to get it based on "p=fffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f"? |
|
|
|
it will confirm the association of bitcoin with other shitcoins, on a protocol level [bad press confirmed]. Yes, and that's why it should be introduced in a different way. The mainchain should not know, how many sidechains there are, and if there are any sidechains at all. It should be made in the "always was possible" way, for example by signing coins. By looking at some output, nobody should know, if it is a part of the sidechain or not, in the same way as you don't know, how many parties there are in a single Taproot address. |
|
|
|
Your statement can be rephrased as "nobody likes their share of the pie to be decreased". I can rephrase it further: Bitcoin users don't like their share of the pie to be decreased in some obscure way. Tail supply can be used to hide the fact that users lose their "share of the pie". It is not instantly obvious to everyone. But if you introduce any fee policy, when it will be required to send some of your coins directly to the miners, or your coins will stay unconfirmed if you won't adjust to the rules (so the final effect will be the same as if they would be burned), then it is crystal clear that tail supply is taken from all accounts and given to all miners. It should be crystal clear from the very beginning, that tail supply supporters want to take single satoshis from everyone, and make a new block reward out of it. And all details would then be only about the whole algorithm that will decide, how many coins have to be taken from each account. My point was that it's hard to get tail emission right. Yes, and because it is hard to do it right, then it should be solved by Merged Mining. You want to get new coins? No problem, just mine Bitcoin, and get Bitcoin and BitcoinWithTailSupply at the same time. Then, you will get additional coins outside of the chain, and then all users will choose, which coin they want to use. But I expect that BitcoinWithTailSupply will have many problems, and will sooner or later burn some coins, because of overproduction. It is hard to get all amounts right, so it should be dynamically adjusted, for example by Merge-Mined sidechains. You want more coins? No problem, just create a new Merge-Mined altcoin, and distribute coins, based on Bitcoin shares. You want less coins? Then it's even easier: just burn them. |
|
|
|
I am surprised that this topic grabbed that much attention. But if that's the case, then in this triangle we can see three scenarios: 1) block size increase, a huge attack, it should be solved by compression, to be stopped once and for all, if not, then block size will be always increased, causing future problems 2) violate coin limit, another huge attack, it should be stopped by burning all coins created by the attackers 3) merged mining, it should be deployed correctly (not like NameCoin, there should be a single chain of the heaviest headers that all coins are attached into), that would stop two previous attacks What has to be done is to build a client based on strigent security measures, and then convince core developers to use that. True, sidechains based on this idea are ongoing: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020532.html |
|
|
|
This has been a monero marketing point for a long time. I think we should burn more Monero, for two reasons: 1) to show them that finite supply is better 2) to protest against such proposals I don't know if Monero has some OP_RETURN equivalent (to avoid spam, because sending to some trap address will force all nodes to process that), but if they don't have anything like that, then it may be possible to burn them in a coinbase transaction, so it could be publicly noticed, how many coins were burned. |
|
|
|
That transaction has exactly 1 sat/vb fee rate not below it since it pays 5048 and has 5048 virtual size. Yes, but it was created by joining transactions that were below 1 sat/vB fee rate, see sighashes. Fees decreased because of the price not because "traffic" went somewhere else. People don't want to go below 1000 sats/kvB on-chain, so if you want to make any transaction with lower fee rates, you can get it accepted only in separate networks, where transactions are batched in a trustless way, to form something that will appear as 1000 sats/kvB on-chain, but for users it is cheaper during making off-chain transactions. |
|
|
|
The mempool on your own node does not mean anything to which transactions will get confirmed, unless you are mining as an entity that decides which transactions get confirmed (you are solo mining, or are running a pool). It depends on sighashes. If you can join 500 transactions with one satoshi fee, to reach a single transaction with 500 satoshi fee, then you don't have to be a miner, you can just be a validator. It is ongoing, and there are practical examples, where you can reach fee rates below 1 sat/vB, or where you can even earn something, see testnet3 transaction: 99459ff5ce058067ed87b99f326305768444068a5659dce5ea5f126bfd4b0bda. A pool's nodes could potentially keep these types of transactions, however, they have little reason to confirm these transactions, even if the mempool has no fee-paying transactions because there is an incremental cost for including an additional transaction by way of having a slightly higher chance the block will get orphaned. Keep calm, today 1 sat/vB means "no priority", and anything below that means "joke priority", so all users should be aware that their transaction can be rejected. But so far so good, in the past, it was normal to pay 0.01 BTC as a fee. But it is sad that the community removed free transactions entirely from the "reasonable defaults". However, regular fees can now reach values like 100 satoshis. In the future, I think we could reach even single satoshis on mainnet, if the whole traffic will jump into sidechains or Lightning Network. It is a matter of time, historically, fees were decreasing, when it comes to the number of satoshis. |
|
|
|
More sidechain demonstration: the normal 1 sat/vB fee means 110 bytes per each P2WPKH-P2WPKH pair. Here, each user can pay 105 satoshis per entry, and the validator pays only 85 satoshis for validating all of that, and for enforcing that on-chain. It is trustless, it is based on SIGHASH_SINGLE|SIGHASH_ANYONECANPAY, and it allows reaching lower fees. Those low-fee transactions are broadcasted only on a sidechain, where they are collected, grabbed by some validator, and then that validator can be paid by getting a discount on its own transaction, it is a reward for the whole batching effort. In practice, that validator could earn even more by batching A->B and B->C sidechain transactions into A->C mainchain transaction. But this example shows, what is possible here and now, with no protocol changes, more sidechain features are ongoing. decoderawtransaction 020000000001056d55d01776f9b17c9fb5fb2a0f058ab7e6c41e53ae8664c3168e66715f57222f0600000000fdffffff6d55d01776f9b17c9fb5fb2a0f058ab7e6c41e53ae8664c3168e66715f57222f0700000000fdffffff6d55d01776f9b17c9fb5fb2a0f058ab7e6c41e53ae8664c3168e66715f57222f0800000000fdffffff6d55d01776f9b17c9fb5fb2a0f058ab7e6c41e53ae8664c3168e66715f57222f0900000000fdffffff6d55d01776f9b17c9fb5fb2a0f058ab7e6c41e53ae8664c3168e66715f57222f0a00000000fdffffff05ef1a00000000000016001431758f3a879e6f5de7c360930690090c98bfc19fd71e0000000000001600140e4d33832a5cf1f55f11ff26c7b36b902dafa605bf22000000000000160014267ce5c5540119ccae615291ed82358bcc7289a5a7260000000000001600143df04c045d3ed284bf45b8c6e89fa127bb09bc1aa32a0000000000001600143c84a28cf58857ab84ffd3b97695bfcf0eea9d3802473044022075742ae535f32ecb934344234a4cd858927e8cc3f6a49c538e9c5febdf0b51f802203d9cf9029d7fbe350adc7a14588b230351c60c4f7a22b639c154bb7ecf5315eb832103ac2c72443e7e2c84b9a18e9038f5681b64bc1039bf40b2ed02f9399a03571c5302473044022038f4a35ecd76650287eaf59964deeca18f9216aebf758278ac9d444a853b64240220036ab1d4695f8620ee33388c68164ecae783fdcac1612135e69ade164d981fa78321034fa5e72baea2e4dfff869203f24acd00b5513d10be34c4483550ea8bec88a1e80247304402202b25ae58837e44c4e8a85aa62d93f197553e53d47b0de946ed66600b7d6ed14a02202152b8691386e4e2d535435ee2f0c73bc13116a7aa5f61e873a198da1cdbf31b832102e488eaa75fca4db098764f0ec8496805d2bd947d3c2e81a45009389fc6117ab70247304402204a7402e66380d60e9dc1b675cc8210ecf3254cacd0085f69e6297bd5cc2afde40220050563ce08bfbd5d3bcb04bb05c7076fa7afaadf483a906053c2475507ee4a6a832103596f696ec7cb352e72042d76f2e166c932f8d4f229ea495a5b659a74357f0cd60247304402206c939a48b5da4233afc896e60dce055ed66b56890ee7aafa75b7cecb9b88570302206f6a4e26a0a28f82f413f0bc77caaeabef9d13eb5750472f85ddff1d2ce0970c83210358d6ce36da9453b7e90d63c0d34cbb587d0bd2fc7090504e3c49074ff5a7629400000000
{
"txid": "07168e032760422e31c98642a2ee8013d7da4902485c002761baa2808a8f7eef",
"hash": "c2b56a74cde6750711b34c7700e5bd0476eaeb95313387f7bec68369ed776de2",
"version": 2,
"size": 907,
"vsize": 505,
"weight": 2017,
"locktime": 0,
"vin": [
{
"txid": "2f22575f71668e16c36486ae531ec4e6b78a050f2afbb59f7cb1f97617d0556d",
"vout": 6,
"scriptSig": {
"asm": "",
"hex": ""
},
"txinwitness": [
"3044022075742ae535f32ecb934344234a4cd858927e8cc3f6a49c538e9c5febdf0b51f802203d9cf9029d7fbe350adc7a14588b230351c60c4f7a22b639c154bb7ecf5315eb83",
"03ac2c72443e7e2c84b9a18e9038f5681b64bc1039bf40b2ed02f9399a03571c53"
],
"sequence": 4294967293
},
{
"txid": "2f22575f71668e16c36486ae531ec4e6b78a050f2afbb59f7cb1f97617d0556d",
"vout": 7,
"scriptSig": {
"asm": "",
"hex": ""
},
"txinwitness": [
"3044022038f4a35ecd76650287eaf59964deeca18f9216aebf758278ac9d444a853b64240220036ab1d4695f8620ee33388c68164ecae783fdcac1612135e69ade164d981fa783",
"034fa5e72baea2e4dfff869203f24acd00b5513d10be34c4483550ea8bec88a1e8"
],
"sequence": 4294967293
},
{
"txid": "2f22575f71668e16c36486ae531ec4e6b78a050f2afbb59f7cb1f97617d0556d",
"vout": 8,
"scriptSig": {
"asm": "",
"hex": ""
},
"txinwitness": [
"304402202b25ae58837e44c4e8a85aa62d93f197553e53d47b0de946ed66600b7d6ed14a02202152b8691386e4e2d535435ee2f0c73bc13116a7aa5f61e873a198da1cdbf31b83",
"02e488eaa75fca4db098764f0ec8496805d2bd947d3c2e81a45009389fc6117ab7"
],
"sequence": 4294967293
},
{
"txid": "2f22575f71668e16c36486ae531ec4e6b78a050f2afbb59f7cb1f97617d0556d",
"vout": 9,
"scriptSig": {
"asm": "",
"hex": ""
},
"txinwitness": [
"304402204a7402e66380d60e9dc1b675cc8210ecf3254cacd0085f69e6297bd5cc2afde40220050563ce08bfbd5d3bcb04bb05c7076fa7afaadf483a906053c2475507ee4a6a83",
"03596f696ec7cb352e72042d76f2e166c932f8d4f229ea495a5b659a74357f0cd6"
],
"sequence": 4294967293
},
{
"txid": "2f22575f71668e16c36486ae531ec4e6b78a050f2afbb59f7cb1f97617d0556d",
"vout": 10,
"scriptSig": {
"asm": "",
"hex": ""
},
"txinwitness": [
"304402206c939a48b5da4233afc896e60dce055ed66b56890ee7aafa75b7cecb9b88570302206f6a4e26a0a28f82f413f0bc77caaeabef9d13eb5750472f85ddff1d2ce0970c83",
"0358d6ce36da9453b7e90d63c0d34cbb587d0bd2fc7090504e3c49074ff5a76294"
],
"sequence": 4294967293
}
],
"vout": [
{
"value": 0.00006895,
"n": 0,
"scriptPubKey": {
"asm": "0 31758f3a879e6f5de7c360930690090c98bfc19f",
"desc": "addr(tb1qx96c7w58neh4me7rvzfsdyqfpjvtlsvlpu3jk7)#qn2vdxzt",
"hex": "001431758f3a879e6f5de7c360930690090c98bfc19f",
"address": "tb1qx96c7w58neh4me7rvzfsdyqfpjvtlsvlpu3jk7",
"type": "witness_v0_keyhash"
}
},
{
"value": 0.00007895,
"n": 1,
"scriptPubKey": {
"asm": "0 0e4d33832a5cf1f55f11ff26c7b36b902dafa605",
"desc": "addr(tb1qpexn8qe2tncl2hc3lunv0vmtjqk6lfs94hcxg9)#4rxkuxgt",
"hex": "00140e4d33832a5cf1f55f11ff26c7b36b902dafa605",
"address": "tb1qpexn8qe2tncl2hc3lunv0vmtjqk6lfs94hcxg9",
"type": "witness_v0_keyhash"
}
},
{
"value": 0.00008895,
"n": 2,
"scriptPubKey": {
"asm": "0 267ce5c5540119ccae615291ed82358bcc7289a5",
"desc": "addr(tb1qye7wt325qyvuetnp22g7mq3430x89zd9cx6w0l)#kx5lg7qc",
"hex": "0014267ce5c5540119ccae615291ed82358bcc7289a5",
"address": "tb1qye7wt325qyvuetnp22g7mq3430x89zd9cx6w0l",
"type": "witness_v0_keyhash"
}
},
{
"value": 0.00009895,
"n": 3,
"scriptPubKey": {
"asm": "0 3df04c045d3ed284bf45b8c6e89fa127bb09bc1a",
"desc": "addr(tb1q8hcycpza8mfgf069hrrw38apy7asn0q6r0pn60)#l5an66k2",
"hex": "00143df04c045d3ed284bf45b8c6e89fa127bb09bc1a",
"address": "tb1q8hcycpza8mfgf069hrrw38apy7asn0q6r0pn60",
"type": "witness_v0_keyhash"
}
},
{
"value": 0.00010915,
"n": 4,
"scriptPubKey": {
"asm": "0 3c84a28cf58857ab84ffd3b97695bfcf0eea9d38",
"desc": "addr(tb1q8jz29r843pt6hp8l6wuhd9dleu8w48fchm2v7q)#0s7jv64g",
"hex": "00143c84a28cf58857ab84ffd3b97695bfcf0eea9d38",
"address": "tb1q8jz29r843pt6hp8l6wuhd9dleu8w48fchm2v7q",
"type": "witness_v0_keyhash"
}
}
]
} Edit: There is a validator that earned 97 satoshis, and provided Taproot validation, where users paid 105 satoshis, instead of 112. See transaction: 99459ff5ce058067ed87b99f326305768444068a5659dce5ea5f126bfd4b0bda. |
|
|
|
Zaledwie wczoraj myślałem o tym, czemu nie ma jeszcze jakiegoś sidechaina bitcoina. Po pierwsze: sidechainy Bitcoina istnieją (patrz: Liquid, RSK). Problem w ich przypadku jest taki, że to są "federacje", a co za tym idzie, nie każdy może je wykopywać. Jeśli jednak mówimy o stakingu, albo o sytuacji, w której istnieją "walidatorzy", to taki model może działać na Bitcoinie dzisiaj, tu i teraz, bez pisania żadnego nowego softu. Czyli: nic nie stoi na przeszkodzie, aby zrobić tak, że masz kogoś, kto ma BTC na swoim adresie i kto zrobiłby adres 2-of-2 multisig. Wtedy jeden klucz należy do twórcy sidechaina, a drugi do użytkownika. Ogólnie jest tak, że jeśli zrobisz "OP_CODESEPARATOR <kluczPublicznyAutoraSidechaina> OP_CHECKSIGVERIFY", a następnie dołożysz do tego dowolny Script, który będzie wstawiony przed "OP_CODESEPARATOR", to jesteś w stanie zrobić taki sidechain, gdzie nikt nikomu nie musi ufać. Wystarczy mieć jednego walidatora, który obsłuży cały ruch. A jeśli będzie ich wielu, to też jest w porządku, po prostu każdy walidator może obsługiwać ruch na tych monetach, które dostarcza, w celu zapewnienia płynności. Innymi słowy: jeśli chcesz założyć własną federację, to robisz "OP_CODESEPARATOR <kluczPubliczny> OP_CHECKSIGVERIFY" i ogłaszasz użytkownikom, że podpiszesz każdy Script (ale nie TapScript!) który ludzie dostarczą. Wtedy każdy klient może zapewnić wejście do sidechaina, jeśli zrobi transakcję, która używa dowolnych wejść, natomiast na każdych wyjściach, zakończonych wspomnianym Scriptem, będzie to znaczyło, że monety są w sidechainie. Wtedy można ustalić hash transakcji oraz numer wyjścia, podać walidatorowi (który nie musi znać treści Scriptu) i wtedy wystarczy, że taki walidator to podpisze. Kolejnym krokiem jest ruch wewnątrz sidechaina. Jeśli walidator będzie wiedział wystarczająco dużo, żeby podpisać transfer z jednego adresu na drugi, to może się to sprowadzać tylko do zmiany adresu docelowego. Tak długo, jak długo walidatorzy są uczciwi, to system działa. Wszelkie zagrożenia są wtedy identyczne, jak w Lightning Network, mianowicie: można ogłosić starą transakcję, która przyzna więcej monet którejś ze stron. Jeśli jednak transakcje będą składane, to w takim modelu kradzież będzie niemożliwa, po prostu to wtedy będzie kwestia wyższych opłat transakcyjnych. Alty nie mają podstaw istnienia. Tylko BTC (waluta internetu) i sidechainy BTC (jej zastosowanie). Dokładnie. I teraz pomyśl o tym, że jeśli więcej osób się o tym dowie, to może przy kolejnych monetach wreszcie ktoś oddolnie wymusi zmiany. To znaczy: jeśli kolejna osoba zacznie tworzyć kolejną wspaniałą monetę od zera, zamiast rozbudowywać istniejące, to może będzie można wreszcie odpowiedzieć takiej osobie coś w stylu "po co tworzysz nowe monety?". Bo moim zdaniem nie ma takiej potrzeby, kiedyś miało być 21 milionów monet, ludzie to niepotrzebnie rozdmuchali. Jeśli jakiś altcoin tworzy swoją własną bazę monetarną, to niepotrzebnie dzieli użytkowników. Mamy monetę A z funkcjonalnością A oraz monetę B z funkcjonalnością B. Musisz sprzedać jedną, aby kupić drugą. Po co? Moim zdaniem to bez sensu, skoro technicznie można byłoby sprawić, aby twórca altcoina dorzucił funkcjonalność B na monecie A. |
|
|
|
|
