Bitcoin Forum
October 02, 2023, 03:33:40 PM *
News: Latest Bitcoin Core release: 25.0 [Torrent]
  Home Help Search Login Register More  
  Show Posts
Pages: [1]
1  Economy / Invites & Accounts / Buying invite on: November 01, 2014, 06:11:28 PM
I need one invite, please PM if you have it and willing to sell it

You will have to go first on this one unless you are trusted member.
2  Other / Meta / Should abusers/spammers of trust system be removed from the DefaultTrust chain? on: July 18, 2014, 06:07:06 PM
For example, user U1TRA_L0RD is trusted in DefaultTrust from bitpop, while he has unanimously negative feedback that is from DefaultTrust and also negative-spammed Vod.

Should this be handled in general? I do not mean to single out U1TRA_L0RD as an example, there are potentially more such users that do not belong on DefaultTrust. Or should I PM the person that trusts him (in this case bitpop) to resolve this?
3  Alternate cryptocurrencies / Altcoin Discussion / Alternative to hiding away the wallet until launch using signed genesis block? on: June 15, 2014, 12:11:14 AM
Being frustrated with launch delays recently, I was wondering about the effectiveness of keeping wallets secret via a password or waiting to release it, and how ineffective that's proven.

I was wondering if it is technically reasonable to provide a wallet immediately, with the hash (exact) of the genesis block (or an ECDSA pubkey that must sign the genesis block), so the actual mining operations cannot start until after that block is released. Obviously, a bunch of users could modify the wallet of FooCoin to accept a different genesis block (released earlier), though then one can't really call that coin FooCoin.

Can someone clarify if this is doable, or why not?
4  Alternate cryptocurrencies / Altcoin Discussion / [CONCEPT+JAVA TEST VERSION] New, memory intensive PoW algo on: December 30, 2013, 02:36:54 AM
License-related edit: I hereby release the details of this algorithm and the linked gist into the public domain. No warranty is implied or given, and I request but do not require that I hear of any coins that get created using this algo. Implementations are free to modify their implementation to suit their language needs freely.

Edit: I've created a self-contained Java version and made it available on Github Gist. Some differences exist from the description below, and as far as I can tell the code is in better shape in terms of design than the description below. All byte[]<->BigInteger conversions are big-endian, though if anyone wants to write a C version it can differ slightly from the Java version, as long as it itself is consistent. I've also noticed that u and v values were not deterministic, and in some cases one can get away with a lower u value and still a good proportion of the same hashes, as a mining optimization. The values must be consistent for verification, however.

Lately, I've been noticing a small trend in PoW algos, geared toward increasing memory requirements and decreasing ASICability. Fist came SHA, which was highly compact and fast on ASICs, followed by Scrypt and memorycoin's POW algo in the mix as well. I'd like to propose to take it a step further, and on that note, make it tweakable to suit an altcoin and even a given moment in time.

Similar to Scrypt, large amounts of data are used as intermediate parameters in a given hashing computation. This data, however, would extend to multiple GB of data in the blockchain(or any coin-specific data set like the UTXO set, as long as it can be replicated consistently), as well as a practically limitless amount of extra disk data, the size of which is configured by the coin itself.

Each set of disk-intensive hashes leaves the ability for a miner to try some different nonces in order to avoid making the entire mining operation grind disks, though disks will remain a large portion. 7 configurable values exist, called t, u, v, w, x, y, and z, in addition to a difficulty value acting similarly to how bitcoin handles difficulty values. t, u, v, w, x, y, and z will be discussed at the end. q is also a specialized parameter.

To begin, a first nonce is chosen, and hashed with the rest of the coinbase using SHA256, twice. This will produce a 256-bit hash, obviously. The hash is taken modulo ((size of blockchain or other coin-specific data rounded down to multiple of 1024) + 7). Such a modulo is a slow operation, and difficult for any potential optimizations. The result is then used to select a position, and length is selected according to hash % (65537), which is a prime which complicates certain naive implementations of modulo by increasing the time needed.

The data selected by the offset and length is concatenated onto the old hash, which is then hashed and processed in the likewise manner x times more. The data itself must be replicable (entire longest-chain concatenated would work) for a given block to be mined.

Once that is complete, a new portion of the algorithm kicks in, which will provide even more RAM-capacity resistance on smaller blockchains.

In this, y hash operations will be performed in a loop on a piece of data, where each operation uses newHash = H(oldHash+M(oldHash)) where + is concatenation and m is, in pseudocode:

hval = input
do for *z* times:
    hVal = H(hVal XOR H(
                     prm +
                     [*u* highest bits of decimal portion of 11th root of P((hVal % *w*)) ]

return hVal

where P(n) is q^n, and *u* is parameter u from above. prm is just some constant to be determined by the coin. It may be the coin's name, some message, a prime, but must remain constant for a given block. It ma be defined based on the previous block.

The square root must be calculated by a specific iterative algorithm where ϵ is less than 2^(-v). Strict conformance to IEEE 754 without wider intermediates (akin to java's strictfp keyword) is required.

This operation is extremely difficult to do at high speed, and must be cached on disk for mining. A single verification will still be able to function without this massive memory requirement. Depending on w, this could require massive amounts of disk space.

After y such hashings, the resulting hash can be concatenated with a strictly t-bit nonce, and hashed by a simple SHA256. This nonce allows for some disk-less operation, but is limited by the generation params.


u: Multiplies size of second-stage cache, requires special handling in n-th root operation if larger than what the FPU can handle alone due to its supported number widths.

v: Determines how much floating-point calculation goes into stage 2. This will determine time needed to create the cache. If prm is defined to be based on the block, a cache for stage 2 would have to be recreated with each new block, meaning that floating-point results must be separately cached.

q: This may be set per-block or statically. If per-block, it would require all floating point data to be recalculated per block. It may be defined as pi or e when static, and should be irrational or fully use the maximum precision afforded by an IEEE 754 double.

w: Determines how many different floating point results must be cached. Larger means direct disk space requirement increases.

x: Basic timing parameter for stage 1, specifying how many blockchain/other per-block data set lookups would be needed.

y: How many stage 2 rounds.

z: How many stage 2 hashes in each round.

The performance breakdown for verifying a hash without cached data is:

y*z* log2v floating-point operations for taking roots. y*z incommensurable floating point exponentiation operations.

x mandatory disk lookups

2*x + y*z SHA256 hash operations

All of these parameters can be tweaked by the coin, whether every certain number of blocks, akin to difficulty adjustments, or fixed. The former would benefit from a coin that can detect what kind of mining power is gaining a monopoly.

Edit: Added parameter t. This parameter can make or break ASIC exclusion and some of the goals of this PoW, by putting it in the sweet spot where the high-end disk-laden servers discussed below are not needed, but an ASIC or even possibly a GPU would perform too much IO to disk to be justifiable. Of course, if one wishes to favor massive disk-laden servers, they can set this parameter to be lower.
5  Economy / Services / Seeking a 1 BTC escrow for software dev on: December 29, 2013, 10:40:13 PM
Hi all, I'm seeking an escrow worth 1 BTC for writing some specialty software for a client. Since I cannot use a tracking number or shipping details for proving a delivery, I plan to use unit-tests to prove delivery. I would give the unit tests to both the client and the escrower by e-mail to establish a contract.

Once the job is complete I'll deliver the software itself by e-mail to both the escrower and the client, using CC in email and a recognized email provider (GMail) so that it is verifiable that an email has been sent to the client with the software.

Is this someone's willing to do? I'll be looking at trust feedback quite a bit, but fees factor into this as well.

6  Bitcoin / Project Development / [CONCEPT] Blockchain-based Minecraft-like game on: December 25, 2013, 05:22:08 PM
Honestly, I'm probably not going to have much luck implementing this (I've had enough trouble implementing a Java blockchain reliably and an Infiniminer voxel engine by themselves), but I might as well share the idea Grin.

While this might end up as little more than a gimmick game, its handling of crypto-currency could potentially integrate with real cryptocurrency like Bitcoin or litecoin through valuable game materials being bought and sold.

Basically, the point is that one can "mine" resources within the game and use said resources in order to work on one of multiple "worlds", which would likely be similar to Minecraft-like worlds. As the client mines a series of merge-mined blockchains corresponding to various types of materials, whether in a pool or individually, they will get materials and tools such as coal, iron, and the like.

In addition, things like crafting and smelting will occur where a given set of coins corresponding to, say, coal and iron, are destroyed and steel is created in a transaction (in its own blockchain corresponding to proof of work of smelting/crafting).

Land can also be obtained by mining one of the blockchains. As you get coins you can spend them on land. This land would then be only usable by a given private key, unless that key is shared or a one-of-n multisig is set on that land.

Any coin, at any given time, would either be in the inventory or placed. When in the inventory, it would be spendable as a regular coin, while when it is placed it can't be spent until it's moved to the inventory address before becoming spendable.

Instead of tools being used, tx fees would apply to placing and removing blocks.

All chains would have relatively fast blocks (15 seconds), and varying rewards based on the commodity they represent.

The client would also include a 3d voxel engine for rendering the world.

The terrain would be generated through perlin and a pre-defined seed. Since anyone can pick any unclaimed land there's no real need to justify a seed too much. That being given, people will still need to mine in order to be able to pay fees even if they use the free dirt and stone they find on their plot. It would be the one commodity that would be generated upon buying land from mining landclaims, instead of being mined directly.

If you have comments or criticism (even if it's just "this will never work, you're a nut job") feel free to reply.
7  Bitcoin / Project Development / [ALTCOIN] ShardCoin [CROSSPOST] on: December 02, 2013, 12:59:57 AM
I'm trying to plan an altcoin that allows for small-scale mining without creating new blocks by incorporating certain nonces that may be mined up as transactions into an existing block. However, I'm not highly proficient in the implementation of bitcoin(the design is OK for me) so I'm just proposing it and hacking off bitcoinj quietly in the background.
8  Alternate cryptocurrencies / Altcoin Discussion / [PROPOSAL/PLANNED] ShardCoin on: November 30, 2013, 10:59:45 PM
First of all, I'm most definitely not using C++ for this as my knowledge of it sucks. I'm likely forking bitcoinj for this, and using that as an official client. I know basic to moderate cryptography/cryptology and have studied the technical design of bitcoin, but I am self-taught so my terminology is likely crap.

This thread is extremely likely to change or die depending on my personal responsibilities and free time, as well as how coding goes. There is NO ETA. With that said, let's get started.

ShardCoin? Yes. A coin that can be created in shards. Perhaps an interesting idea, perhaps a stupid one. We'll see. In traditional bitcoin mining, every single coin created is created at the minting of a block into which transactions enter. The miner gets their 50 25 BTC and tx fees and is happy. But what about all these uber-small miners out there, trying to mine? Pools? An external solution to an internal concept problem.

ShardCoin is somewhat different, in that the network carries two difficulties depending on mining successes and the current hashrate. The first, high difficulty, is extremely similar to the bitcoin network. A working nonce reaching this difficulty will get their share of coins, as an input into the block's transactions paid to the miner. This is targeted to happen once every 2.5 minutes. Read on.

The second difficulty is much easier compared to the first. A nonce meeting this difficulty will NOT create a new block, as that would bloat the blockchain crazily. These will be targeted to be generated once every few seconds, network-wide. Nonces are tried with a different set of fields. However, if these nonces do not create blocks, what is their purpose? They would actually become transactions granting a certain number of coins to a given private key. The public key, the nonce, and details about the current block(serial number and perhaps its hash) are included in this hashing calculation. If this meets a difficulty as hashed, it is entered as a transaction into the blockchain, except with no inputs and the nonce/public key/block ID provided. The address provided now gets their share of spendable, transferable coins after 6 confirmations. A double-spend could likewise occur in this case without these confirmations.

This operation, however, carries a small fee, needed in order for mega-miners to accept the generation. This fee would need to be sufficient in order for a miner to value adding these transactions over manipulating the currency by deliberately denying them entry. That is a pitfall that must be addressed.

Difficulty calculations will act to keep the rate of creating blocks to once every 2.5 minutes, and creating mining transactions every 5 or so seconds on the network.

The hashing method may be scrypt, but it could also be expanded requiring lookups in random locations on the blockchain, forbidding mining on disk-less devices without appreciable losses of hashing power.

Economics and planned release:
I'm really going to need some feedback here. I plan to pre-mine 256 blocks of this coin in order to establish a chain. The coins from the first 256 blocks would be defined as unspendable in the code but would count toward difficulty calculations (especially important early on).
9  Economy / Services / [no longer selling service] on: November 30, 2013, 12:01:39 AM
10  Other / Archival / Delete on: April 23, 2013, 12:55:23 AM
Hi. I am trying to remain anonymous, so there's absolutely no way I can prove to any of you I'm not a scammer, so hopefully at least someone out there trusts me. I'm seeking a 0.2BTC loan in order to invest in merged/union mining. I will pay back 0.225 bitcoins in 5 weeks.

11  Other / Beginners & Help / 51% attack--Truly 100% success? on: April 22, 2013, 10:06:47 PM
Reading about the 51% attack, I'm understanding that it relies on the attacker generating blocks. Since hashrate USUALLY(but not 100%) corresponds to the block rate, isn't the attack success not 100% since an attacker with a marginal majority of power be often stopped by the block rate fluctuation?
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!