zpalmtree

Migrating from fixed fees to fee per byte

Welcome, developer!

As you may have seen, we are moving to utilising a minimum fee per byte at block 2,200,000. For more information on the reasons behind this decision, please check out this article from the core team: https://blog.turtlecoin.lol/archives/the-turtlecoin-journey-2-years-and-counting/

What do I have to do?

If you have an application which sends transactions on the TurtleCoin network, you will likely have to update your code to work correctly with fee per byte.

zpalmtree

Unmixable inputs / MixIn count is too big

I can't send a transaction, what's going on?

When you receive a transaction, the amount is split into thousands, hundreds, tens, ones, etc. So if you are sent 1234 TRTL, this is stored as 1000, 200, 30, 40 in your wallet.

When you want to send a transaction, regardless of how much you are sending, you have to use these stored amounts. If we wanted to send 10 TRTL, and you only have a 1000 TRTL input, you have to use this.

Ok, but how does this relate to my transactions failing?

zpalmtree

Keybase proof

I hereby claim:

• I am zpalmtree on github.
• I am zpalmtree (https://keybase.io/zpalmtree) on keybase.
• I have a public key ASDM1wsH6bP8TggJ7YRq42mGKh2WQ-rQS1fYdybPdW3HqAo

To claim this, I am signing this object:

zpalmtree

#include <iostream>
#include <vector>

const uint8_t PORTABLE_RAW_SIZE_MARK_MASK = 0x03;
const uint8_t PORTABLE_RAW_SIZE_MARK_BYTE = 0;
const uint8_t PORTABLE_RAW_SIZE_MARK_WORD = 1;
const uint8_t PORTABLE_RAW_SIZE_MARK_DWORD = 2;
const uint8_t PORTABLE_RAW_SIZE_MARK_INT64 = 3;

template<class T>

zpalmtree

# xmr-stak doesn't currently support the algorithm that turtlecoin uses after the 350k fork, so we can use xmrig instead
# xmrig is similar to xmr-stak, and some prefer it's output and config files
#
# Unfortunately it doesn't support combined gpu and cpu mining, so you have to run one instance for your nvidia/amd 
# and another for your cpu

# Download links:
# xmrig (cpu) - https://github.com/xmrig/xmrig/releases (You probably want xmrig-2.6.0-beta1-gcc-win64.zip if you're on windows)
# xmrig-nvidia - https://github.com/xmrig/xmrig-nvidia/releases (You probably want xmrig-nvidia-2.5.2-cuda9-win64.zip)
# xmrig-amd - https://github.com/xmrig/xmrig-amd/releases (You probably want xmrig-amd-2.6.0-beta1-win64.zip)

zpalmtree

void printTxOutputs(Crypto::Hash transactionHash)
{
  std::vector<TransactionDetails> transactions;
  std::vector<Crypto::Hash> transactionHashes;
  transactionHashes.push_back(transactionHash);

  m_node->getTransactions(transactionHashes, transactions, callback);

  TransactionDetails ourTransaction = transactions[0];

zpalmtree

#!/bin/bash
# This script is for Ubuntu 17.10 x64
# You will need to edit the config to add your pools and wallet address.
# SSH into the server, then run this command to execute the script:
# bash < <(curl -s https://gist.githubusercontent.com/ZedPea/d8ff315c052701f5ffd3a4ad249bd985/raw/d7150695238f033b2d78e871024e6c6cb99e65e8/vultr.sh)
# Of course, your url will be different as you will have had to edit it to setup your own pools.
# Perhaps make a gist of your own, then click "Raw" to get the raw sh file you can execute directly on the server
# Of if you find it easier, you can just copy this into a .sh file on the server - chmod +x file.sh; ./file.sh
# Update repos
sudo apt-get update -y

zpalmtree

Q: Can you speak more about your Mobius development milestone? A: The goal of the Mobius milestone is to be able to have fast blocks with a shorter chain. The end goal being that a normal user can board the network, form transactions, and go about their business without worrying about syncing transactions that happened 10 years ago at 30 second block speeds. If you look at how big the chain is from a size perspective, compared to bitcoin, not only are fast blocks working against us, but our security features make us a little bit more beefy when it comes time to broadcast a transaction. From a technical perspective, there are several ways we can accommodate this. The first way that I explored was pruning. This is a concept that is employable on many networks, and the gist of it is that in cryptonote project, you can prune two ways: one is from a network level, like in Boolberry, and the other is to have a multi-tiered daemon system where you can have full reference daemons(or historical daemons as some people