Hi,

I finally decided to close my hobby shop for mining. Wondering if any of you is interested in 20x Bitmain S19K PRO 120TH units? They are about one year old.

Payment in bitcoin on delivery (delivered to you where you can test all/some).

If interested PM me your offer and delivery location (city at least).

Block's new ASIC chip and soon miners sound much needed considering current ASIC manufacturers business practices. Let's collect news/updates here.

[ASICJUNGLE is LEGIT and they DID deliver the machines. Also fixed the ones we sent back]

Hi Guys,

Just to share our experience if someone plans to buy from asicjungle.com.

They did deliver and overall, they are legit and easy to work with. In our case the problem was that they sold used equipment with warranty (DOA X days). Claim which they didn't fulfill. It is actually somewhat worse as they did work with us and we agreed on a fair amount (with Alex B.) of which they just didn't pay. I mean after several months and many promises that they will.

Thing is, we were only brave enough to buy the used S19s because they did offer this warranty, without it we wouldn't.

So as always: just be careful.

Bye
Gabor

Note: Edited on 10/06 and would like to add:
ASICJUNGLE is LEGIT and they DID deliver the machines. Also fixed the ones we sent back . Our issue is about the repairs we made on-site. As of our understanding they did imply to pay for these, yet they didn't (implied = they asked for an invoice of the parts used).
Doing on-site repair is against their policy. Even when the cost of on-site repair is actually close/less to the UPS fee to send the unit back.

Hi Guys,

We are experiencing somewhat high failure rate with S19K PRO machines. Hash boards start to fail (chip lost) after 3-4 months. So far about 6% failure rate in <6 months usage... (warranty repaired, but some failed again)

I mean S19J was not perfect, but K seems to be way worse.

Machines were bought new and in a few different batches (albeit close to each other).

Anyone has actual experience with these units?

Cheers

Hi,

We are having delivery issues with blokforge.com. Delayed order (months) and nothing but excuses.

In the past they were a reliable provider of mining gear. We bought from them a few times with little/no problems.

Just wanted to raise awareness as they may have serious issues and/or planning a rug pull?

Please share if you are having similar issues.

Cheers

[The Goal]

Hi,

I came up with a great enhanced proof-of-work concept, I call it optimized Proof of Work and I think it's brilliant
I am not removing any PoW. PoW will still be needed to create blocks, so you would earn the same amount as today with same hashrate. The only difference would be the 99.8% electricity saved.

The Goal
Save 9X% percent of power used for mining without lowering the security mining provides.

Proof of concept
- After each period (lets say 2016 blocks) there would be a special/different block of which would include all the miners wishing to mine and their best hash. Using low enough difficulty miners "boost mine" for let's say an hour and would include all the calculated hashes in this "proof-block".
- The miner mining the 2016th block would create and broadcast the proof-block. This block would include the PublicKey of the miners for each 2016 future blocks in order of creation and expected time of creation.
- After this all mining would stop and order of miners who allowed to create a block would be sealed in the proof-block
- The miner would have a +/- 1 minute range (relative to the expected time the given block should be created) to build, sign and broadcast the block. This signing would be without actual PoW, just using his PrivateKey corresponding to the PublicKeyHash in the proof-block. PoW would be referenced only in the proof-block.
- If the miner didn't broadcast the block in time then the next miner would have the right for 1 minute, after the next miner after the next, etc.. This way it would be guaranteed that a block will be created even if the miner is not available. for any reasons.


Advantages
It would save ~99.8% percent of power cost (1 hour mining time vs 336 hours today)
Block structure would be the same so as the coinbase transaction and creation speed, transactions, etc.
It would keep the chain safe, I believe the same or more as today (maybe more as the two weeks block production is "locked" so no slowing down/speeding up under the period)
It would keep blocks almost exactly 10 minutes apart
It would keep Bitcoin mining the same or more diversified than today

Disadvantages:
You need to have at least 1/2016 of the total hashrate to mine (who is mining with less today?)
Miner needs to be online at the time you are needed if not loosing the slot (so be online: redundancy, etc.). I belive 200K$ is incentive enough to invest into 2-3 distributed servers.
Those creating replacement blocks (if someone missed his slot) would get free(ish) blocks, but they provide a service so I think it's fair.

I know that changing the consensus and hard forking is though/almost impossible, but it may be doable with the voting like with taproot.
 
Please shoot and let me know why this wouldn't work

[But:]

Hi,

I don't want to be alarmist and this is not a Bitcoin dies FUD post. Just a theory as there is no proof.

The fact I started with:
50+% of mining capacity disappeared from the Bitcoin blockchain which has never ever happened. Difficulty is adjusting as it should, so nothing to see there.

But:
What IF this is a stealth syndicated attack by Chinese miners?

Example/imagine:
They didn't really shut down. They just forked the Bitcoin blockchain and started selfish mining ever since on an alternate private chain (eg. withholding all the blocks they find and building their own private chain). They can do this for long time and release at once the new, longer chain. As it has more PoW (as long as they have the majority hashrate) it will become the only chain accepted by all nodes. As far as I know there is no roll-back limit, so theoretically they can do this a month later (or more).

All the coins mined on the public chain between the two dates gone. All the transactions may or may not be included. Those with knowledge of this attack could have cheated (like sending coins to exchanges, withdraw the fiat/altcoins and a month later getting back the coin because they sent it to a different address sooner on the alternate chain).

Personally I don't think that the CCP would play along. But that doesn't mean it's impossible.

Do you know any limitation in the protocol which would prevent this (eg. rollback limit?)?
Do we have any hard proof that those huge (at least the known really big ones) mining farms are actually off?

Cheers
Steve

Hi,

I think this has never happened before:
15-25% percent DECREASE in hash rate when price is around ATH. As a result blocks are mined slower, fees are high (until next retarget).

https://diff.cryptothis.com/

Does our collective brain have any idea what's going on?
My guess is: Inner-Mongolia said "stop mining by end of April". That province was guessed to host a few % only, maybe it is happening and it was much more hosted there?

Cheers,

Hi,

I needed a BIP39Seed/Mnemonic splitter for fault-tolerant Geo-distributed seed storage.

Here is a small tool. Simple, but does the work.

Cheers,


https://github.com/GhostOfSatoshi/BitcoinSeedSplitter

At the moment windows only, but .NET5 should make it easy to compile a version for Linux.

[Kilobytes]

Hi,

I am trying to set-up a ColdCard to work air-gapped with Bitcoin Core (via SD card). Latest Bitcoin Core 0.21.0 and latest ColdCard firmware used.

- I create a watch-only non-descriptor wallet and I execute the importmulti command created by ColdCard (2x5000 addresses), OK
- I receive the correct addresses from Core which are watch only, OK

- I do a two simle (1in 1 out) test transactions (main-net) when all looks good. Core exports the PSBT ~600 bytes. Coldcard signs it and creates the final TXN ~400 bytes. All good.

BUT:
Later nothing changed (I mean Core closed and reopened few hours later, that's all). New TX arrives. Trying to do the same spend and PSBT export is now ~176 Kilobytes. Takes minutes while ColdCard digs through all of that and finally signs the one used and produces a ~400 bytes TXN.

Nothing fancy is going on, no multisig, no nothing. Why does Core include a lot/all addresses in a PSBT, but only the needed one at the beginning?

Any help would be appreciated as I seem to be stuck.

Thanks
Gabor

Hi,

We work with a ColdCard wallet and Bitcoin Core 0.21 setup.

Everything works fine with legacy wallet format, ColdCard exports an importmulti command and Core has the watch only addresses:
importmulti '[{"range": [0, 1000], "timestamp": "now", "keypool": true, "watchonly": true, "desc": "wpkh([*hash*/84h/1h/0h]*tpub*/0/*)#*hash*", "internal": false}, {"range": [0, 1000], "timestamp": "now", "keypool": true, "watchonly": true, "desc": "wpkh([*hash*/84h/1h/0h]*tpub*../1/*)#*hash*", "internal": true}]'


We would like to move to Descriptor wallet in which case importmulti is not working.
If I just simply replace importmulti with importdescriptors it runs fine, but the wallet is not able to create/give any new address (get new address button is grayed out) getnewaddress returns "Error: This wallet has no available keys (code -4)".


Is there a way to import the xpub to a descriptor wallet (I tried to search, but no results so far) correctly?

Thanks
Gabor

PS:
Original tpubs and hashes were removed from commands.

Hi,

Fully built, powered and tested (operating 24H for about 3 years) mining farm is up for sale.

North Texas (Dallas area) location with evaporative cooling and open air exchange, redundant internet, CCTV, alarm system, remote temperature  monitoring, etc.
750KW capacity (Oncor), ~5c current (4.6c from 2/1) /kWh rate (@80% load WITH ALL taxes and all fees, fixed rate for 3 years). You can also go market price (2.5c and up all in)

Building is ~6,000 sqft LEASE (2K/mo 3y, renewable). Cooling, power, shelves and ventilation can handle ~300 optimized S17s.

Please PM me with any questions.

Bye
Gabor

Hi Guys,

We have a few Bitmain S17 units and the 15K RPM FANs in the PSU started to die (~ 1y old). No problem (we thought). We ordered a bunch of 40x40x28mm 12V ~same FANs and installed them (originals and the replacement are both 12V are 2 wire no PWM type).

And here comes the surprise: Original FAN works from a given FAN header (inside the PSU). Replacement FAN doesn't work from FAN header (inside the PSU) (several PSUs and FANs tested).

But the replacement FANs do work from: 12V test PSU; from the 12V coming from the APW9 PCI-E connector.

Voltage measured on the FAN connector ~12V. Voltage measured on wire of the new FAN, ~12V. So the correct (looks correct) 12V is reaching the new FAN, but the FAN just won't work at all.

Now I am stunned. How can a simple two wire FAN not working if correct voltage applied (and working from the same PSU's PCI-E 12V)?

Any idea would be welcomed as these are relatively hard to come by and not that cheap either.

Original FAN: Nidec UltraFlo  W40S12BMD5-01Z90.

Replacement FAN: Sunon PDM1204PQBX-A Double Ball Fan 12v 8w Fan 40x40x28mm.

Thanks.

PS: Please also advise if you know any online store selling two wire 40x40x28 15k RPM fan's and not shipping from China.

Hi Guys,

I created a watch only wallet and using the ColdCard generated importmulti command to generate Bech32 addresses. All good.

Unfortunately ColdCard is not producing/has BIP44 address commands as an option hence I have to do it manually.

I have the XPUB and I run the getdescriptorinfo to get the hashes than importmulti (Testnet).

Problem is:
Generated addresses seem to be incorrect , ColdCard refuses to sign "BIP32 path doesn't match actual address".

What I changed from original BIP84 ColdCard generated text is in red.
I use pkh instead of wpkh and use 44h instead of 84h.

Any idea how should I import an XPUB to get BIP44 addresses (or better yet what am I doing wrong below)?

Thanks



Modified 44 Main

getdescriptorinfo "pkh([c09dbfcb/44h/1h/0h]tpubDDrejUjS6BXjB2MQBpzxVqED68xiooU7bSHB1qavnUHA5M1gnoNxy8k6UubVoGLgSM28bnTnexc NDg874eVpDVUaPDKyKtA8sD1DZwuhKar/0/*)"
{
  "descriptor": "pkh([c09dbfcb/44'/1'/0']tpubDDrejUjS6BXjB2MQBpzxVqED68xiooU7bSHB1qavnUHA5M1gnoNxy8k6UubVoGLgSM28bnTnexc NDg874eVpDVUaPDKyKtA8sD1DZwuhKar/0/*)#xmx56jg3",
  "checksum": "42etqglj",
  "isrange": true,
  "issolvable": true,
  "hasprivatekeys": false
}

Modified 44 Change

getdescriptorinfo "pkh([c09dbfcb/44h/1h/0h]tpubDDrejUjS6BXjB2MQBpzxVqED68xiooU7bSHB1qavnUHA5M1gnoNxy8k6UubVoGLgSM28bnTnexc NDg874eVpDVUaPDKyKtA8sD1DZwuhKar/1/*)"
{
  "descriptor": "pkh([c09dbfcb/44'/1'/0']tpubDDrejUjS6BXjB2MQBpzxVqED68xiooU7bSHB1qavnUHA5M1gnoNxy8k6UubVoGLgSM28bnTnexc NDg874eVpDVUaPDKyKtA8sD1DZwuhKar/1/*)#h0r488cf",
  "checksum": "y7u2aa02",
  "isrange": true,
  "issolvable": true,
  "hasprivatekeys": false
}

importmulti '[{"range": [0, 199], "timestamp": "now", "keypool": true, "watchonly": true, "desc": "pkh([c09dbfcb/44h/1h/0h]tpubDDrejUjS6BXjB2MQBpzxVqED68xiooU7bSHB1qavnUHA5M1gnoNxy8k6UubVoGLgSM28bnTnexc NDg874eVpDVUaPDKyKtA8sD1DZwuhKar/0/*)#42etqglj", "internal": false}, {"range": [0, 199], "timestamp": "now", "keypool": true, "watchonly": true, "desc": "pkh([c09dbfcb/44h/1h/0h]tpubDDrejUjS6BXjB2MQBpzxVqED68xiooU7bSHB1qavnUHA5M1gnoNxy8k6UubVoGLgSM28bnTnexc NDg874eVpDVUaPDKyKtA8sD1DZwuhKar/1/*)#y7u2aa02", "internal": true}]'
[
  {
    "success": true
  },
  {
    "success": true
  }
]

[It fails with: Expected type number, got object.]

Hi,

I am trying to RPC interface with Core and use walletcreatefundedpsbt with the following JSON:

{
   "jsonrpc": "1.0",
   "id": 6,
   "method": "walletcreatefundedpsbt",
   "params": [
      [{
         "txid": "a77564bb72336febc5fe620bc67586dcc014bad6bb1c3aa53e3b01bb6159f241",
         "vout": 0,
         "sequence": 0
      }, {
         "txid": "a77564bb72336febc5fe620bc67586dcc014bad6bb1c3aa53e3b01bb6159f241",
         "vout": 1,
         "sequence": 0
      }],
      [{
         "tb1qgz5yfluv3n0sjcadxhmm3dk4xrwlglr88vsj8k": 0.00349723
      }], {
         "subtractFeeFromOutputs": ["tb1qgz5yfluv3n0sjcadxhmm3dk4xrwlglr88vsj8k"]
      }
   ]
}

It fails with: Expected type number, got object.

But, it works if subtractFeeFromOutputs option is not used, so I assume options should be included somewhat differently.

Unfortunatelly docs or google didn't help me to solve this

Can you please tell my how to modify this JSON?

Thanks

Hi Guys,

Just asking because I don't like to be scammed, so asking before buying :

https://microbtmining.com/

This seems legit, but I am still not sure as no-one should have m30s according to some twitter accounts.
(because of the corona virus)

Do you have any experience with this site? Is this legit?

Thanks

Hi,

What happens after chain reorg with the transactions confirmed on the shorter chain (lets assume a somewhat possible 3 blocks reorg), but not included in the longer chain? I believe those are not in the mempool anymore as they were included in a block earlier.
Does Bitcoin core re-queues the transactions from the overwritten blocks?
Does it x-reference which transactions were included in the loosing but not he winning fork?

Can someone please someone enlighten me?

Thanks

[Let's do a theoretical here:]

Hi Guys,

Let's do a theoretical here:
Let's assume that some exchanges are not honest and they not only inflate their volume, but they actually sell what they don't have. So they have 1000 real BTC in their possession, but they sell (and hence promise to pay out) multiple times of that. Hence creating fake/paper/on the books Bitcoin out of thin air. I recall this is the reason of the yearly "not your key not your coins day", but still: probably most of the users don't participate.


My thinking:
If you sell BTC and receive FIAT it is VERY likely that you will withdraw it. Because you "know" FIAT it's better/safer at the bank and you already have an account. Not to mention that the Exchange's bank reserves are easier to check by the authorities (assuming a regulated exchange which most of them are nowadays). So it is much easier for them to get into trouble if they create fake FIAT balance.
BUT
If you do the opposite: sell FIAT and buy BTC I believe that it is more likely that the you will leave it on the exchange (or the exchange's custodial "wallet") for long long time.

My point is:
It is way (probably multiple times?) easier for the exchanges to create fake BTC liquidity. Because of this their price pressure/manipulation capability is magnitudes higher on pushing BTC price down than on push it up.

Thanks for reading this far, what do you think?


PS:
"You" stands here as a placeholder for the average user, not "us".

[But:]

Hi Guys,

There is a lot of talk recently about Decentralized Exchanges.

I kind of understand how a DEX can operate inside a single blockchain or even between two blockchains.

But:
I simply don't get how can you use a DEX for FIAT<>Bitcoin? I mean there are no visible smart contract on the FIAT side. So the SWIFT/FIAT transaction really can't be verified (I hope we won't count a bank print-out "proof of wire" as proof). Without this "little detail" one can't prove the FIAT side at all. Of course the crypto seller can "ok" the FIAT when arrived and release the funds, but what if he/she claims it didn't arrive? How can the sender proove (and to whom)?

As far as I know 3rd parties (wire to an intermediary/escrow) is not really an option (legally). It would also make the transaction and the exchange pretty much not decentralized.

Please enlighten me, if you can

Thanks

[very]

I do believe that this could be advantageous in some cases:
after a very long time sender should be able to "call-back" a still unspent UTXO

Our current case:
A customer used Samurai wallet (on our advice ) and backed-up the seed words from the devices as they were ordered (restore was also tested!).
Unfortunately Samurai changed it a while back to mandate a passphrase for new wallets (I believe it was always there, but optional). Which the customer didn't back-up (as we told them to keep the seed words which was true at that time). We weren't aware as we didn't create new wallet in Samurai for a while.
Now they face loss of access to some of their Bitcoins because a phone was lost. They tried to restore from the seed (without the unknown passphrase), but they ended up with different root key hence they see zero balance (they have tried what they could as passphrase).

I don't blame it on Samurai as they clearly state this in the app and you even have to click a checkbox to agree. Still I kind of feel sad and thinking about solutions. I also believe this causes serious blow back for Bitcoin even among those trying to be responsible.
They do know the TXID in question (still unspent) and they do have the private key of the source UTXO.

My thinking is something like this:
After a given time (years) it could be a good option for the sender to be able call back/invalidate a still unspent transaction.

I believe this could help a lot of people to reclaim lost funds. I know this is a big one (maybe a silly too) one and won't be fast if ever happens. Goes a against the basics too, but not so much I believe as if someone want's to avoid this possibility he/she would only need to move the funds and that would make this "re-call" impossible.

Thanks

PS:
Those who have seed words only as backup for Samurai should check if it is enough for successful restore (on a different phone!) while they still have access to the original wallet.

Any idea how long would it take to brute force the passphrase with lets say 6 characters long (and check which one has balance...).