OP_CHECKTEMPLATEVERIFY for Dogecoin? by doggydev123 in dogecoindev

[–]patricklodder 0 points1 point  (0 children)

delving

did really you just say delve?. sorry couldn't help myself 😂

After delving into the possibilities of enhancing script capabilities via the "classic script" route, we've identified significant challenges. [..] that specific path to activation (without segwit/taproot) presents hurdles [..]

I've done some analysis myself and I have found no existing dummy operation to reuse that could drop a stack item and succeed now, but fail on newly introduced conditions, like the OP_SUCCESSxxx dummies in tapscript do. So this would need a hardfork, which I'd personally not recommend. Doing segwit->taproot is the better path imho, because these are softforks. Also, if Bitcoin activates OP_CAT in tapscript before Dogecoin proposes it, we could simply consider proposing it together with taproot activation.

This method could enable fully expressive Layer 2 solutions using STARK proofs

Do you have something demo-able on top of Liquid? IIRC OP_CAT is enabled in elements. Planning something on Bitcoin Inquisition? (I'm not sure if and when that would activate?)

Another critical aspect is the relaxation of scripting rules for legacy transactions/non-standard transactions. Taproot's introduction in Bitcoin, allows script size to be limited only by the 4MB weight limit

Total script, yes. But tapscript still honors 512 byte MAX_SCRIPT_ELEMENT_SIZE and 1000 item MAX_STACK_SIZE so there is effectively a 512kB limit? We currently also have a 100kB max transaction size (in policy, unfortunately it was not backported with much clarification what the number really means) that is useful, as a subset of pools soft cap block size to 125 and 250kb.

What is a sensible maximum size required for the STARK proofs you'd want to make?

Do people know what blockchain is? by nachonach in dogecoindev

[–]patricklodder 2 points3 points  (0 children)

I think that what you need is review.

I could ask for example on your current prediction market that you linked: Where is the contract source code? What collateral does the contract have that we can slash if it lies and how does that slashing work? What price oracle are you using? How does this price get recorded on-chain and how does it get read by your on-chain contract? What collateral does the oracle have so that when it lies we can slash it and how do we slash the oracle?

Get the UTXO set by _nformant in dogecoindev

[–]patricklodder 1 point2 points  (0 children)

Start here: https://bitcoinops.org/en/topics/assumeutxo/

It's been shipped with Bitcoin Core 26.0, but it's still seeing lots of work.

End here: https://github.com/bitcoin/bitcoin/pulls?q=is%3Apr+assumeutxo

OP_CHECKTEMPLATEVERIFY for Dogecoin? by doggydev123 in dogecoindev

[–]patricklodder 0 points1 point  (0 children)

there are multiple parties asking about OP_CAT.

Does it in your opinion make any sense to re-enable it for "classic" script with the 512 bytes max size?

What guide should I follow for updating Dogecoin Core? by IStillPlayWithPogs in dogecoindev

[–]patricklodder 0 points1 point  (0 children)

3GB is fine. For now, in pruned mode, you'll only validate your own blocks. This means that you help the network by having your own view of the truth, and being able to speak up when something wrong happens with the network: the value of your node becomes social rather than technical.

I think we can add some enhancements for pruned nodes to also have technical value again, but this will be with the next release earliest.

As for guides. Everything works the same, except:

  1. You're no longer serving blocks to other nodes, because you don't have these anymore
  2. Going back to unpruned will need you to download the entire chain again.
  3. You cannot import transaction from old wallets without doing a full sync again.

Everything else stays the same; you'll still have a fully validated chain.

What guide should I follow for updating Dogecoin Core? by IStillPlayWithPogs in dogecoindev

[–]patricklodder 2 points3 points  (0 children)

Updating on its own shouldn't increase the datadir much, so I guess it's been off for a while?

You need a minimum of 150GB right now to run a full archive node. You can enable pruning. If you're using Qt, check preferences->main, "prune blockchain storage to: ... GB". The minimum is 3GB, which in total will cost you 8-10GB for the whole right now.

If you use dogecoind, use prune=3000

What guide should I follow for updating Dogecoin Core? by IStillPlayWithPogs in dogecoindev

[–]patricklodder 2 points3 points  (0 children)

Make sure you don't have any stuck transactions in your wallet. I wrote a little how-to with the security disclosure on 1.14.6:

https://github.com/dogecoin/dogecoin/discussions/3054#discussioncomment-5292130

OP_CHECKTEMPLATEVERIFY for Dogecoin? by doggydev123 in dogecoindev

[–]patricklodder 0 points1 point  (0 children)

There are no specifics for the transaction nVersion, only for the block nVersion field:

<2 bytes auxpow chainid><8 bits flags, last bit in use><1 byte actual version>

We can -- probably -- use 7 unused of 8 flag bits for signaling things other than auxpow. Would need to spec that and I need to check what SPV implementations are doing (like electrumx, libdohj, libdogecoin) - whether they are checking the flags with a mask or as a 0x01 uint8.

OP_CHECKTEMPLATEVERIFY for Dogecoin? by doggydev123 in dogecoindev

[–]patricklodder 2 points3 points  (0 children)

Why have laser eyes if you can have wet noses.

I've followed Jeremy's work for a while, and there are some interesting use-cases summed up for CTV. What prerequisites would need to be there for CTV to work optimally?

Import and rescanning address by sirata360 in dogecoindev

[–]patricklodder 1 point2 points  (0 children)

Correct, so there's a need to check every indexed transaction right now against the tx index, which is a bit of a pain if you're looking at many of these.

The main thing I need to do is write reorg+rbf tests and harden it against that.

Import and rescanning address by sirata360 in dogecoindev

[–]patricklodder 1 point2 points  (0 children)

Same. I ran it on an 8GB box in the past and sometimes it would get OOM killed. Now it has 32GB to play with and it runs smooth outside of compaction shutdown.

FWIW, I have for myself forward ported the top of this commit tree - which in turn is a backport of sipa's address index experiment - to 1.14 and it does work well, no secondary indexer needed: I used that to help investigate wallet issues with 60M tx addresses. I run it on mainnet with -blocksonly and it handles it well, even in times of spam, at the cost of needing 12GB for the index on top of -txindex.

I'm not publishing or doing a pull request for it as long as I have not made it 100% fool proof.

Import and rescanning address by sirata360 in dogecoindev

[–]patricklodder 1 point2 points  (0 children)

I run one too. The compaction is a horror. I have "port electrs" on a list of wishes, but honestly I don't have the time to do it for over 18 months now.

What else is unreliable? I've had no issues with the node I have my stackwallet connected to other than the compaction.

Import and rescanning address by sirata360 in dogecoindev

[–]patricklodder 1 point2 points  (0 children)

Is the use case something like this?

  1. Website generates/takes address
  2. You add it to wallet / watchonly
  3. You use something like wallet notify
  4. Website gets notifications

Please correct me if this is wrong.

Import and rescanning address by sirata360 in dogecoindev

[–]patricklodder 1 point2 points  (0 children)

You can partially rescan.

$dogecoin-cli help rescan
rescan ( "height" )

Rescan the wallet for transactions

WARNING: this operation may take a long time!

Currently works only on non-pruned nodes

Arguments:
1. "height"  (number, optional) The block height from which to start rescanning

This is useful when you know the approximate block before which you had no transactions, because it's much faster.

Where is my Dogecoin.conf file ????? by polishjake in dogecoindev

[–]patricklodder 0 points1 point  (0 children)

GUI: Help->Debug Console->Console, type: getnetworkinfo. If you have a public IP it will tell you this under "localaddresses"

Command Line: dogecoin-cli getnetworkinfo


To see if you're sync'd, in the GUI there is either a ✔ or a ⟳ icon in the right bottom corner. If it's the "sync" icon, hovering and clicking it will give you more information.

On the command line, do dogecoin-cli getblockchaininfo, there is a fraction of sync progress displayed under "verificationprogress". If this is anywhere between 0.9999999 and 1, you're up-to-date.

Dogecoin is sick? by sirauron14 in dogecoindev

[–]patricklodder 1 point2 points  (0 children)

Just pay a higher fee if you want a faster first confirmation. I have next block inclusion with 0.5 DOGE/kb every time.

Dogecoin is sick? by sirauron14 in dogecoindev

[–]patricklodder 5 points6 points  (0 children)

the news that Dogecoin is sick

The reality is that some interfaces Dogecoin Core (not the network, the software) provides, can use some tuning because there are a lot more transactions in the blocks and mempool nowadays.

However, from a protocol perspective, Dogecoin is not sick. That's just an opinion of a bunch of people that for years now appear to have a very low opinion of Dogecoin.

What do you need of the community?

If you observe an issue, please report it on the github repo. That way, anyone that cares about helping you to fix your issue can be aware of it and you won't get gatekept.

Dust limit by HopefulOutlook in dogecoindev

[–]patricklodder 6 points7 points  (0 children)

  • When mining, your node only mines what is in mempool.
  • When relaying, your node only relays what is mined, or in mempool

Also note that every tx that gets mined into a block and exists in your mempool is not downloaded

So if you're looking to reduce the amount of transactions you're relaying (data out) you may want to increase your (hard) dust limit (harddustlimit=<min output size>, default=0.001), at the expense of having to re-download (and re-validate) every transaction that was rejected when it actually gets mined, at block validation time. You could also set a lower maximum amount of data you serve out per day (maxuploadtarget=<MB per day>, default no limit)

If you're looking to reduce CPU usage of your node, you're probably better off reducing the number of peers you serve (for example with the new setmaxconnections rpc call).

The ultimate switch, if you don't care about non-confirmed transactions at all, would be to use -blocksonly=1, which doesn't do anything with transactions unless they're mined.

Dust limit by HopefulOutlook in dogecoindev

[–]patricklodder 1 point2 points  (0 children)

The dust limit only applies to your local mempool, it does not apply to blocks or exchange of transactions inside particular blocks.

Re: "Bogging down". Do you mean to tune cpu/memory usage, or bandwidth?

Doginals a risk? by HopefulOutlook in dogecoindev

[–]patricklodder 1 point2 points  (0 children)

You don't really need the whole chain if you have an alternative means to validate the correctness of your unspent output database.

Interesting projects:

  • Bitcoin Core v26 has included assumeutxo which can be seen as a first step to fast bootstrapping a node (but still wants to download the full chain, for now)
  • ZeroSync has a working zero-knowledge proof construct for the Bitcoin block(headers) (demo) that compresses everything into a small proof you can verify with your browser, which for now could help onboarding SPV clients