|
bump. any updates on this? code or design wise...
|
|
|
|
|
bump for comments from theoretical types.
|
|
|
|
The major new feature in 0.1.8 is support for segwit addresses (p2sh and bech32) via ypub and zpub extended keys used by some 3rd party wallets. Also added/changed since 0.1.5: - blockcypher and btc.com can be used as api providers for funds lookup queries.
- blockr.io api provider removed -- no longer exists.
- auto-retry api providers 3 times in case of connection glitch
- minor fixes and improvements
|
|
|
|
I wrote a tool hd-wallet-derive that will derive addresses for 300+ altcoins. In this case, you would give it an xpub for each altcoin, so the private key never needs to be on the server. You could pre-generate the addresses, or gen each one on the fly by recording the last used index. To be safe you should verify that the first 2 generated addresses actually match your wallet's addresses for each coin before accepting funds. |
|
|
|
I wonder if there are logs of that IRC channel from back in 2009/2010 somewhere... or for that matter, ~/.bitcoin/debug.log from some time period... Rather Bitcoin used an IRC channel to announce your node's IP address and allow other nodes to discover other nodes to connect to.
|
|
|
|
To be precise you should think abstract.
Abstractly speaking, efficiency of a device is a matter of algorithm and the machine which runs it. As long as you keep hashing algorithm unchanged, you can't change the distribution of efficiency.
This proposal, does not cover ASIC problem that makes commodity devices uncompetitive. What it tries to fix is the mining scale effects on devices with same efficiency (hundreds of thousands of ASICs distributed unevenly in different scales).
yes, I get that. And I don't expect cell phone mining to ever be really profitable vs asics, gpus, botnets or whatever. Even against only other cell phones each one would only have like a 1/billionth share. Fundamentally, I'm just thinking of an ideal algo that is provably fair, ie pays out according to work performed, and each device added actually provides more security to the network. Given such a system, more people might mine altruistically, and perhaps people could use it to generate some micro-tokens for participation in the network without having to visit an exchange of some type. Like 21, inc used to talk about: bootstrapping towards internet of value/things. Stated another way: today I could turn on a dusty old laptop and start it mining to give me warm fuzzies that it is helping secure the blockchain. But I know that it isn't really achieving anything because it would not find a block in my lifetime and those cycles/elec have been wasted due to winner-take-all. But if I knew that my tiny contribution was actually additive with everyone else's tiny contribution each block, and also we together are providing resistance to consensus rule changes, then I would probably do it, even if not profitable. From my initial read of your proposal, I understood the work to be additive, not winner-take-all, and thus would give me the warm fuzzies with my dusty old laptop or my cell phone mining. is that not so? could it be made so? |
|
|
|
Let me tell you a secret: I forced myself to take care of pools just because of the same cause you distinguished and pointed out: consensus changes.
I was working on ASIC resistance proposals when I realized for any consensus change, instead of convincing the community I have to convince few pool operators, the very job I'm not good at. Actually I suck negotiating with authorities of any kind, I feel desperate and worthless and it always ends to the same result, being humiliated by a bunch of idiots who got no brains and no hearts.
Then I started asking myself: Shouldn't it be different with crypto? wasn't it supposed to be different? Haven't I been promised to leave in a more decentralized planet? Why should I have to negotiate when I have the logos on my side? Who gave them the ethos to sit with me and negotiate?
It was how I left everything else suspended and started to design this proposal.
I want to set crypto free for further evolutions, to make it a fair environment for the most important resource on the earth: human's creativity and talent. It is why I'm so proud of this work. It is right to the point, the most important point ever after Satoshi: elimination of pooling pressure in PoW consensus systems.
I agree with and support your above statements. I would simply maintain that your goals may be most readily achieved by letting bitcoin be bitcoin, and start something new. permission-less innovation and no need to convince anyone. I understand your concerns but some thoughts:
1- We made bitcoin what it is.
We propagated and defended it. We introduced it along with Ethereum and Monero and others to our friends, our family, our colleagues enthusiastically and confidently. We are responsible against the community that we contributed in building it, we just can't leave them alone with Jihan, it is not fair.
We each also agreed to bitcoin's consensus rules, as they are/were when we began using it. I've argued elsewhere that the ideal cryptocurrency in terms of maintaining a stable and trusted value is one whose consensus rules cannot be changed, ever. In practice, what we have now with BTC and ETH are coins that are quite difficult to change, by design, so anyone that tries will likely be frustrated. What you are proposing is a major change to the rules, so you will likely be frustrated. That I happen to agree with your reason/goals is irrelevant to that basic point. 2-PoCW, this proposal, is about eliminating the need for pools in a network saturated by hashpower and transaction load. Releasing a fresh coin based on this protocol is a feasible option but it may take too long to have such a network under a real stress test and it would put the project in the risk of being obsolete and lost in the hypes and speculations.
I believe that if this algo works as intended and a coin is fairly launched, a lot of people would mine it from day 1, and it would be under a real stress test long before your proposal would be adopted on bitcoin mainnet. For now, my plan is neither a fresh coin nor a traditional hard fork. I'll discuss it later when I'm more ready. But If hypothetically, somebody is interested in releasing a new coin using this protocol, I'll support technically and mentally.
Ok, cool. Sounds like you have a plan. I won't belabor that point any longer. Yes I am and I will commit my work asap.
Actually, after some coding I found myself with a lot of new ideas and improvements (it happens very often, the code thinks and designs autonomously) so I went back to my papers and decided to release a new version of the proposal with a LOT of interesting improvements.
I suppose it takes quite a time but worth it. Will keep you informed.
Excellent! I will look forward to that. One should be careful here.
What we fix is mining variance and its centralization consequences, mining profitability and efficiency is another whole damn issue, damaged by ASICs.
Hmm, here I get a little confused. Your proposal states: The Idea is accepting and propagating works with hundreds of thousands times lower difficulties and accumulating them as a proof of work for a given transaction set, letting miners with a very low shares of hash power ( say of orders like 10-6) to participate directly in the network and yet experience and monitor their performance on an hourly basis.
Also in your writeup on the mining variance you state: while small miners are losing opportunity costs every single round, they will never have a practical chance to be compensated ever.
From these statements, I inferred that your proposal intends to enable practical mining on "small" devices. If that's not really the case, I would encourage you to define what is a "small miner" and what the goals are in terms of hardware participation, as this directly relates to how decentralized mining can practically be. a blue-sky aside: I have always thought that a theoretically "ideal" decentralized POW consensus algorithm would reward every participant that contributes computes cycles to securing the network, in proportion to the work performed, each and every block. Practically speaking, this would seem to require breaking the share puzzles into chunks small enough for each device to solve multiple shares per block, according to its abilities. It also might require something like lightning to make regular micropayment payouts to thousands or millions (or billions) of mining participants worldwide: think everybody with a smartphone wallet app. The aggregate coinbase payout amount could be recorded onchain. maybe such an ideal algo will always be pure fantasy. What do you think? |
|
|
|
|
@aliashraf First, thank-you for this proposal and for moving the ball forward on POW improvements to increase decentralization.
Please do not let trolling or forum moderators get you down. Sometimes it is better to ignore the noise and focus on building.
Anyway, having skimmed over the entire thread, here are my initial thoughts.
1. This is important work. One aspect of pooling that has only been lightly touched on in this thread is the power that pool operators have when it comes to consensus changes. During the segwit debate, pool operators would signal this way or that and the individual miners operating on those pools had no say in the matter, except to leave, which some did but not many. The exact same thing happened with the eth/etc fork over the DAO debacle. It is quite possible that neither of those consensus changes would have happened without pools. In my view, a truly decentralized POW would result in a coin that is MUCH MUCH more resistant to consensus algorithm changes because it is like herding wild cats (many asleep and hiding under brush) instead of influencing a few zookeepers. This improves immutability. If consensus changes are actually desired, a formal change mechanism such as Decred's can be built-in.
2. It is admirable that you wish to help bitcoin and eth with this improvement. However, this is a long and frustrating road you have set yourself, full of politics and headache. B. Fuller said "You never change things by fighting the existing reality". Sometimes it is necessary to create a viable working alternative just to prove something can be done. Just look at monero and zcash. People have been talking about improving privacy in bitcoin pretty much since day 1. We still don't have it. But at least now we have choice, and some working implementations that can serve as testbeds for things like bulletproofs that may yet find their way into bitcoin. So I would encourage you to reconsider your stance on building an altcoin. A fairly launched, decentralized coin would not be a "shitcoin" in my book, but a chance to start over and do some things right. If the innovations are better, that coin will eventually win in the marketplace or have its innovations adopted by larger coins. Truly decentralized mining, if achievable, is an idea worthy of its own coin, if ever there was one.
3. Are you working on code already? I'd be interested to check out github for this project....
4. What are your goals for who would be able to profitably mine on such a network? For example, would every person on the planet with a smartphone be able to profitably mine? How about raspberry pi or even an old commodore-64? I'm just trying to get an idea of what the lower limits are for contributions to the network's security, and also I would like to understand if such "micro-mining" requires or supports micro-payments. Eg payments for value that might be worth $0.00000001 cents in today's value. Do fees become the limiting factor? Is 1 satoshi too large to express some of these mining rewards?
5. You may find the bitcoin-dev mailing list a better audience for deep technical discussion/feedback.
|
|
|
|
Hence, while small miners are losing opportunity costs every single round, they will never have a practical chance to be compensated ever. Right. This is a huge disincentive to mine for most. It seems that the "perfect" pow of algo would reward every mining participant exactly in proportion to their work expended towards securing the network, no matter how small without variance, and without need for mining pool middlemen that take a cut. This should incentivize almost everyone to mine. A practical problem is that rewards for such mining efforts are likely not even representable by the native blockchain token, eg less than 1 satoshi, and also fees are prohibitive. I will read your proposal. |
|
|
|
|
You said: "the algorithm change will be instant or near-instant". That's not really possible in a decentralized system where the code is deployed to many places already unless that code has a built-in mechanism to fetch updates and synchronize when they activate together. But that mechanism itself becomes a point of centralization. That's the problem you would need to solve, imho.
|
|
|
|
bitcoin-core implements hd-wallet key derivation differently from most 3rd party wallets. This release adds support for bitcoin-core style key derivation with these two features: - new flag --addr-type=[legacy|p2sh-segwit|bech32|auto]. Allows to override automatic address-type detection based on key-type.
- x' in bip32 path to request hardened key for derived addresses. ex: --path="m/0'/0'/x'".
Here's an example: $ /home/websites/hd-wallet-derive/hd-wallet-derive.php --path="m/0'/0'/x'" --addr-type=p2sh-segwit --cols=path,address,pubkey --numderive=3 --key=xprv9s21ZrQH143K3KeCJ5DMac7XqmriV7xVDDCV5MNE564bKUF6piF7JK6RWHVJMzQMUBbzxLaV9kNaRMHyjVnjNiLAq2SyvJJBs7ZUg4c9kcy -g
+------------+------------------------------------+--------------------------------------------------------------------+
| path | address | pubkey |
+------------+------------------------------------+--------------------------------------------------------------------+
| m/0'/0'/0' | 3LTKKaLjr83nSCEE5gUfLzRhavU3wAdMtu | 0236ac3d8df99023e259d24754fd022af696542e25ff237bc9c835d52468b538ae |
| m/0'/0'/1' | 34dCyjA9rEtjDEZ1AUViTGxYvmNAFA3gFH | 0365d31a6168e1187202ffb30bc80b4a788d68e87909024b624d4963ff2426b339 |
| m/0'/0'/2' | 3FzQckSqoQNnzdGgn5sLRUgaE8Vxt4g4eo | 02446804c9bd85f0f782a0f4e52baa7398005b0ee54dc4eed23aeef64363a7ea99 |
+------------+------------------------------------+--------------------------------------------------------------------+
|
|
|
|
|
Interesting research. Please keep posting your findings. Do you plan to build/release a tool for people to make atomic swaps?
Well you clearly know more about atomic swaps than I do, but I would guess there are so many types because multiple parties have implemented them in isolation and for different blockchains.
|
|
|
|
Possible if the scanner's output combines the QR input with one or more other inputs (one of which could be the EPOCH time segment the scan has been made).
interesting, can you expand on this idea? my musings: this requires a new derivation scheme, does it not? eg, one could not use a standard bip32 xpub for this purpose. But supposing both receiver and payer's wallet support the derivation scheme based on (seed + timestamp) then I suppose that to find payments the receiver's wallets has to derive all possible keys in possible time ranges. This seems a bit computationally expensive and begs the question of what resolution to use for timestamp (milliseconds, seconds, minutes, hours). Too large and addresses may be re-used many times. too small and the number of keys to check becomes huge. or is there a better way? |
|
|
|
Hmm.... well one could certainly write code that does something like: code = fetch_url('http://asicresistantpow.org/algo/lang/mylang')
eval(code)
But this raises some issues: - What if the code can't be fetched? mitigation: Presumably it would be cached and would not activate until X utc timestamp, specified by algo source
- asicresistantpow.org is now a huge central point of control. It can be compromised via coercion, extortion, bribery, insider greed, etc, etc. mitigation: ??
One thought to avoid the centralization issue but still allow change is to use something like decred which has a built-in governance mechanism for change control. So if the pow algo were itself hosted on some sort of decred-like decentralized blockchain, that might be a starting point, though what's to prevent gaming by large players...? It's a hard problem. |
|
|
|
I just released version 0.4.0 of hd-wallet-derive. This is a big release. The major new things are: - segwit support for bitcoin and most btc derived coins. (segwit keys for other coins is super highly experimental)
- both p2sh (y) and bech32 (z) segwit addresses are supported.
- support for LTC Ltub/Mtub style keys in addition to xpub/xpriv
- support for LTC new style p2sh 'M' addresses.
- lots of test cases
- various bug fixes and enhancements.
At this moment, I believe this tool will generate keys/addresses for more blockchains (including testnets, regtest) and in more variations than any other tool on the planet. See the readme for details and examples of using segwit keys. |
|
|
|
I just released version 0.3.2 with support for deriving ethereum addresses, as well as generating random HD master keys. enjoy! $ ./hd-wallet-derive.php --coin=ETH --mnemonic="athlete alone tent cherry motor able gym lobster mad ahead peanut anger congress segment horn hidden crater host thumb audit sugar casino produce garment tag rose planet law gather human drop analyst tank cabbage casino hybrid fun science wheel bring insect helmet million guide survey grace save top" --cols=path,address --numderive=3 -g
+------------------+--------------------------------------------+
| path | address |
+------------------+--------------------------------------------+
| m/44'/60'/0'/0/0 | 0x92C4210c2fbC3237efb8a93611d0E61c3936E84b |
| m/44'/60'/0'/0/1 | 0x4b7A3CFc314D92447a8F2Ebe3F7b93D469bC195b |
| m/44'/60'/0'/0/2 | 0x1702ebaA4cD9AD453ea45569e27B877338d48862 |
+------------------+--------------------------------------------+
|
|
|
|
I just released version 0.3.1. Some big improvements: - Support for deriving keys/addresses of 300+ altcoins, 90+ with bip44 path support. Mostly bitcoin clones.
- Added --gen-key flag to generate a new master key, mnemonic, seed, and extended keys for any supported cryptocurrency.
- Use bip44 path by default when --mnemonic is specified.
- Added --bch-format flag to display CashAddr format or regular Bitcoin format.
Here's a few examples: Let's find what altcoins are supported.$ ./hd-wallet-derive.php --helpcoins
+--------------------+------------------------------------+
| Symbol | Coin / Network |
+--------------------+------------------------------------+
...
| ZEC | Zcash - Mainnet |
| ZEC-test | Zcash - Testnet |
| ZEC-regtest | Zcash - Regtest |
...
+--------------------+------------------------------------+
(340+ altcoins omitted for brevity) Derive some Zcash addresses$ ./hd-wallet-derive.php --key=xprv9zbB6Xchu2zRkf6jSEnH9vuy7tpBuq2njDRr9efSGBXSYr1QtN8QHRur28QLQvKRqFThCxopdS1UD61a5q6jGyuJPGLDV9XfYHQto72DAE8 --cols=path,address --coin=ZEC --numderive=3 -g
+------+-------------------------------------+
| path | address |
+------+-------------------------------------+
| m/0 | t1V1Qp41kbHn159hvVXZL5M1MmVDRe6EdpA |
| m/1 | t1Tw6iqFY1g9dKeAqPDAncaUjha8cn9SZqX |
| m/2 | t1VGTPzBSSYd27GF8p9rGKGdFuWekKRhug4 |
+------+-------------------------------------+
$ ./hd-wallet-derive.php --coin=DOGE --gen-key --format=jsonpretty -g
[
{
"coin": "DOGE",
"seed": "a3adc3e71ac05b3336422e6506d646e995f7bfcb960e6fca48dc13c93fae8ef3dc37a6013791ad1cfe7fe408de0e7676a9fe29b02413c79b988d54c74515d3db",
"mnemonic": "arch hover pen regret priority sugar thunder glimpse west diagram path sword divide spread anger vendor century roof agree know treat drastic allow blind advance oil iron gold skate absorb stem shiver can pear twin helmet loan satisfy fragile admit comfort mercy pelican pupil debate tornado rifle desert",
"master_priv_key": "dgpv51eADS3spNJh8eoSPqujdFPAhBZywAW6KQrR5TqM1Q5NMsrJmFP1hTXvfbUHLQFLmh4jVYZjXtJvKJVakn5YxT48mocEXu7yTNkCYN29cMV",
"path": "m\/44'\/3'\/0'\/0",
"ext_priv_key": "dgpv59SfnUBjPvKLfM453bkxJXHRfNvDQ3zAngt3fpKheqR846z9W1QYzoUz5ss4qtvLU7iBd93nw8ZXcXArpdLjuyudR2uUFH4KeV9Nes8eNeJ",
"ext_pub_key": "dgub8tKh8A7cx4yfxCiE5qNvRNq27wHrEB1t5HfFpvigSxU8cA6qumxKe6tdf7TkUPFBoj6C8eBxofiydXy5hGf471zWZkYiy4tQ6vWqRwETdGA"
}
]
|
|
|
|
I made a tool that parses bitcoin derived codebases and extracts relevant info for each cryptocurrency, including testnet and regtest networks. So far, over 300 altcoins have been parsed, many with testnet and regtest settings. I believe this to be the most comprehensive listing of altcoin parameters yet produced. The data is made available in a single JSON file for use in any language, and also there are language bindings for JS and PHP that make installation and usage dead simple. There are also human readable summary tables in markdown format: I began collecting data because I needed bip32 prefixes for my hd-wallet-derive tool. However, it was a fun exercise to parse source repos and the project took on a life of its own. I figured the data could benefit others working on multi-coin projects. Available data for each coin / network includes: - symbol and name
- Urls: website, github repo, block explorers, announcement
- number of decimal places
- Key prefixes: public, private, p2sh, bip32 xpub, xprv, bech32, bip44
- p2p port and rpc port
- DNS seeds
- p2p magic bytes and signing magic prefix
- genesis block hash
Tokens are not included and no plans to do so. XMR, ETH, and DCR are included and other non-bitcoin derived coins are welcome if people want to submit pull request for them. The data, code, and more examples are on github. Feedback, comments appreciated. Please report any issues on github page. |
|
|
|
update: I've made a couple minor releases since the last time I posted here. Present version is 0.1.5. Changes since 0.1.3: - Adds support for btcd as an API provider for finding used wallet addresses. So one need not rely on a 3rd party API provider to find all wallet addresses that have ever been used.
note: btcd does not provide received/sent/balance info for each address, so those fields are empty. - removes toshi from roundrobin list because toshi.io is no longer available.
- now runs under php7 (as well as php5.5+)
- Fixed bitwasp dependency version problem with php7.
|
|
|
|
|
Show Posts
