Bitcoin Forum
August 15, 2022, 07:55:39 PM *
News: Latest Bitcoin Core release: 23.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1]
1  Bitcoin / Development & Technical Discussion / getblocks vs getheaders on: March 25, 2020, 01:25:00 PM
Hi everyone,

I'm currently mid way through converting Bitcoin 0.19 based client so that it can properly synchronize from a pre-0.10 clients chain.
Those who are in the know should automatically know exactly which currency i'm talking about.

So far i'm having good luck but seem to run into an unusual and undocumented problem.
Every 500 blocks received via INV request, seem to come with an extra block at the end that reflects the current chains tip.
Everywhere i've read suggests that *only* 500 blocks are sent, but I always seem to get this extra block tacked onto the end.

Quote
2020-03-24T15:44:05Z ComputeNextStakeModifier: prev modifier=0x000000105dbc2bd6 time=1545703144
2020-03-24T15:44:05Z ComputeNextStakeModifier: no new interval keep current modifier: pindexPrev nHeight=499 nTime=1545703144
2020-03-24T15:44:05Z UpdateTip: new best=0000000105a7e280f68b5d030282998640d6da2fa0eb107e9dd65a3e7ccad9d8 height=500 version=0x00000003 log2_work=8.9686668 tx=521 date='2018-12-25T02:01:18Z' progress=1.000000 cache=0.1MiB(676txo)
2020-03-24T15:44:06Z ERROR: ProcessNewBlock: AcceptBlock FAILED ( (code 0))
2020-03-24T15:44:08Z ComputeNextStakeModifier: prev modifier=0x000000105dbc2bd6 time=1545703144

It doesnt actually affect sync at all, but it bugs the s**t out of me.

Yes neckbeards, this isnt technically 'bitcoin only' discussion; but I think its a heartwarming change from 'howTO cloening of the cOIN'.. and technical discussion, which this forum has sorely lacked over the past few years.

james
2  Alternate cryptocurrencies / Mining (Altcoins) / Profitability equation on: May 05, 2017, 06:15:38 AM
Hi all,

As we know, scrypt profitability (or hashes required to solve for a block) can be represented in the following equation:
difficulty * (2^32) / blocktime = estimated_hashes_for_block

The equation differs for x11, however this is limited to the center part (2 to the 32nd power).
Does anyone know what this value needs to be to suit x11 algorithm coins?

james
3  Alternate cryptocurrencies / Altcoin Discussion / Nonstandard P2PKH in Altcoins on: March 27, 2017, 03:50:41 PM
Hi all,

Realise this isn't exactly bitcoin related, but there doesnt appear to be much in the way of indepth technical talk in the other subs.

I'm writing some code that deals with transactions for yr standard X11/POS clone, to find that the transactions seem to be missing the byte that denotes inputs/utxo's; as well as differing in a ton of other ways.

for example:
Code:
010000004b1fd95801a696effab44fcc8c01dce6fbe3326ec630b350297820c709ee3821eaa3b4a365010000006a473044022047f3fb936f8174b373ad91485b011ae82f97791f97298a12f78ee43eae1f1827022002842cf172229640d8ff6c13178ef66f15f81c4352ce01bbc17d2e8b6d01d75f012103dbe6d1236d1352efd00af6359b7f66f266db6bb42abc7bc32671894820ce64a3ffffffff02bcbc1300000000001976a9142741acc7d11257a8bcc880608f995390cb2ad05a88ac40420f00000000001976a91439b16a2b091ef397bc81162add65246667fb987988ac00000000

this transaction has txid '92695e12e62fed76a27cb5199e227e6f6ba3b3b667e273b1b09b4c8f339ef96f":
Code:
{
  "version": 1,
  "time": 1490624512,
  "locktime": 0,
  "vin": [
    {
      "txid": "65a3b4a3ea2138ee09c720782950b330c66e32e3fbe6dc018ccc4fb4faef96a6",
      "vout": 1,
      "scriptSig": {
        "asm": "3044022047f3fb936f8174b373ad91485b011ae82f97791f97298a12f78ee43eae1f1827022002842cf172229640d8ff6c13178ef66f15f81c4352ce01bbc17d2e8b6d01d75f01 03dbe6d1236d1352efd00af6359b7f66f266db6bb42abc7bc32671894820ce64a3",
        "hex": "473044022047f3fb936f8174b373ad91485b011ae82f97791f97298a12f78ee43eae1f1827022002842cf172229640d8ff6c13178ef66f15f81c4352ce01bbc17d2e8b6d01d75f012103dbe6d1236d1352efd00af6359b7f66f266db6bb42abc7bc32671894820ce64a3"
      },
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 1.2935,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 2741acc7d11257a8bcc880608f995390cb2ad05a OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a9142741acc7d11257a8bcc880608f995390cb2ad05a88ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "NPVYDQo2gyYBGnWsFS8eNTF1XyBDvRZX9o"
        ]
      }
    },
    {
      "value": 1,
      "n": 1,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 39b16a2b091ef397bc81162add65246667fb9879 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a91439b16a2b091ef397bc81162add65246667fb987988ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "NRB2EgTQKxPQmTH3apzTrvjWHjA9V2Fm66"
        ]
      }
    }
  ]
}

i can't seem to find any bip/standard that this sort of transaction conforms to, and most bitcoin/litecoin push-tx handlers don't understand it.
any ideas?

james

4  Economy / Gambling / Satoshidice.com having issues? on: December 03, 2016, 05:22:01 AM
Hi all,
Wondering if anyone else is experiencing issues with SatoshiDice; have laid down 0.25BTC, but unable to bet or withdraw.
Keeps sitting there with 'processing your bet' and upon withdrawal, sits there doing.. not much.
Usually site works fine?
james
5  Bitcoin / Development & Technical Discussion / pchMessageBytes on: September 03, 2016, 11:57:59 PM
Hi all,

I was reading a while back regarding the way the Bitcoin/Satoshi clients talk to each other; it seems that they first send a version-type packet, and if the other client sends a version that is too low, or with different parameters that do not match (for example pchMessageBytes); the client will not respond whatsoever.

Is there any known way to get a remote node to effectively reveal its unique pchMessageBytes?
Besides bruteforcing/pattern scanning (as there are 256^4 or 4,294,967,296 different combinations).

Please don't reply if its simply 'why do you want to do that'.

james
6  Alternate cryptocurrencies / Mining (Altcoins) / Gridseed Blade Recovery/Design questions (GC3355 based) on: September 12, 2015, 08:34:08 AM
Hi all,

This has been bugging me for a while, and i'd rather just know as opposed to potentially frying some equipment..

A mate of mine lent me his cache of well looked after Gridseed Blades, to muck around with and test out. All of the units worked, aside from one which has one dead PCB (since removed). After a LOT of messing around, I was able to determine that the MCU/RS232 TTL hardware on this PCB had died and have since removed the chip from the board (this is after making sure it wasnt a case of bad firmware etc).



Can anyone say for sure, that the role of the STM32Fxxx MCU is purely for translating from USB to RS232 TTL? I've read that it has a hand in setting the voltage for the GC3355's.. does it also handle multiplexing for communication to each hashing IC - or are they all wired in a common bus layout (hence the ID selection for each GC3355).

I'm not particularly keen on installing a new MCU to the board, however I would be game enough to solder the 4 or 5 wires required for a MAX232CPE (for a regular PC serial port to TTL convertor) as well as the 3.3/5v required in the same PCB area.

The GC3355 datasheets on github (https://github.com/gridseed/gc3355-doc/blob/master/GC3355_1Chip_EVB.pdf and https://github.com/gridseed/gc3355-doc/blob/master/GC3355_8Chip_Sch.pdf) don't seem to rely on an MCU being present - which makes me think that addressing through UART-alone might work.

I'd also previously owned a Zeus Thunder X3 - which literally let you chain each blade like it was on a 'bus', which supports my thinking of this being possible.

Can someone please set me straight on this; only if you know..
james

Pages: [1]
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!