Bitcoin Forum
June 25, 2021, 03:16:58 AM *
News: Latest Bitcoin Core release: 0.21.1 [Torrent]
  Home Help Search Login Register More  
  Show Posts
Pages: [1]
1  Bitcoin / Development & Technical Discussion / A proposal to decrease the blocksize limit on: September 04, 2015, 04:27:00 PM
I've gotten a bit bored of all these block size increase proposals so here's a proposal to extremely decrease block sizes.

So let's say we take our good ol' blocks and we just just chop them down so there are no scripts, nor does a transaction even hold any numerical data. All a transaction is, is an arbitrary packet of data, which would probably be most useful as a hash, more on that later.

Field | Description | Size
Magic no | identifies network | 4 bytes
Blockheader | consists of 6 items | 77 bytes
transaction | the transaction | 4 bytes

Because we know the transaction size ahead of time, and the block size is also uniform, those fields have been removed entirely.

tiny-Block Header;
Field |   Purpose | Updated when... | Size (Bytes)
Version   Block version number | You upgrade the software and it specifies a new version | 1
hashPrevBlock |   256-bit hash of the previous block header | A new block comes in | 32
hashMerkleRoot | 256-bit hash based on all of the transactions in the block | A transaction is accepted | 32
Time | Current timestamp as seconds since started | Every few seconds | 4
Bits | Current target in compact format | The difficulty is adjusted | 4
Nonce | 32-bit number (starts at 0) | A hash is tried (increments) | 4

I reduced the version field to 1 byte, but left the rest of the block header the same.

That leaves us with some nice 85 byte blocks. So we could have this blockchain running on almost every device that exists, and over a 200 year period, there would be about 10518980 transactions, or about a 894MB blockchain.
I suspect technology should be able to keep up with this storage capacity requirement.

At first consideration this whole thing seems totally silly, after all, what could we possibly do with a system that can only accept 1 transaction per 10 minutes, and does zero verification of the transactions it's accepting?
As it turns out, I think there's quite a bit that could be accomplished with this kind of system.

I would suggest that this root block chain would be the hashpower provider of larger data structures, so for example, if we wanted to attach Bitcoin to this, all we would need to do is mine a block on this tiny-blockchain which contains a hash of a Bitcoin block.

The new Bitcoin block header might look like this;

Field |   Purpose | Updated when... | Size (Bytes)
Version | Block version number | You upgrade the software and it specifies a new version | 4
tiny-hashPrevBlock | 32-bit FNV-1a hash of the previous block header | A new block comes in | 4
tiny-hashMerkleRoot | 32-bit FNV-1a hash based on all of the transactions in the block | A transaction is accepted | 4

The Time, Bits, and Nonce fields can all be removed because this is all provided by the tiny-blockchain. The hashes can also be dramatically reduced because the hash does not have to be cryptographically secure, all it needs to do is be fairly resistance to collisions. Note that the tiny-blockchain is storing a hash of potentially very large Bitcoin blocks.

A miner would run the tiny blockchain software, but not necessarily the Bitcoin software. A miner may be configured, by extension, to accept a hash along with a promise of payment of bitcoins. (What that "promise" looks like, could vary widely.)

Now a Bitcoin "miner" would necessarily run both it's own software along with the tiny-blockchain software and wait for a tiny-blockchain block to roll in (or mine one itself).
Then it will wait for a block to come in that matches the hash in the tiny-blockchain block (or create one itself, if it self-mined a tiny-block).
Then it will verify that this block legitimately follows the rules, if it does not then the block is ignored (Or broadcasts it's own blocks).

Since the Bitcoin software fully verifies the blocks, there is no danger of a bad tiny-blockchain block forking the Bitcoin chain, and we have the same level of confidence in the integrity of the Blockchain as we do now.
However, it would necessarily mean that "bad" blocks are permanently stored on the tiny-blockchain.
I don't think this is a big deal. The sheer cost of putting a bad block in the tiny-blockchain should heavily mitigate this sort of behavior.

The biggest problem with this, is that it requires a reasonable degree of certainty that the tiny-blockchain node will be paid, even though the tiny-blockchain node might not necessarily be running cryptocurrency software it's being paid in.
The most straightforward way to resolve this problem is to rely on something I'll call a "Payment Authority" which is just an entity that verifies that payment will occur before it passes the hash onto the tiny-blockchain nodes. On the flipside, the nodes would whitelist the Payment Authorities they trust.
This does not mean that the tiny-blockchain nodes must trust these third parties, as a last resort they can always run the full cryptocurrency software itself and verify the blocks that way.
I know that's not an ideal solution, but off-the-cuff it should at least show that it's not an intractable problem.

There are at least three major advantages to this kind of system.
Since the tiny-blockchain is completely abstracted from the underlying protocols that are providing the hashes it's storing, it is trivial to swap out protocols, or even run more than one at the same time, without forking the tiny-blockchain.
It is also extremely small, so there is a much greater ability to decentralize the proof of the accuracy of any kind of data-set amongst many nodes.
A cryptocurrency could also be highly centralized while proof of it's state is highly decentralized, whereas at the moment those attributes are tightly coupled.

Maybe food for thought, or maybe totally crazy. I'm not so sure myself.
2  Bitcoin / Development & Technical Discussion / Bitcoin without bitcoins? on: May 12, 2015, 07:54:35 PM
So I've been thinking about this on and off for a while, and came back to my attention with the release of the libbitcoin-consensus library in 0.10.0 (Not that it actually has anything to with this.)

It seems to me that it should be possible to run a blockchain that is abstracted from the implementation details of any cryptocurrency that relies on it.

There would be at least two blockchains. One would be the Proof of Work blockchain and the Bitcoin blockchain.

The Proof of Work blockchain would be identical to the Bitcoin blockchain as it functions now except that it does not contain any transactional information, only a list of arbitrary hashes.

If someone wanted to provide Proof of Work for Bitcoin, they would be hashing the previous block header on the Proof of Work blockchain as well as the hash of a current block for Bitcoin (Along with any other hashes they'd want to include) + nonce. The Bitcoin block itself would also contain the hash of the block header of the Proof of Work block that included the previous Bitcoin block. It's possible that several Proof of Work blocks would not include any hashes for Bitcoin blocks.

[Proof of Work Block]
Previous Proof of Work block hash

[Cryptocurrency Block]
Proof of Work Block header hash that contained the previous Cryptocurrency block hash.
Transactional Information

The main advantages I see with this system is that it allows arbitrary experimentation in cryptocurrency designs while retaining PoW infrastructure, it creates a marketplace for Proof of Work hashes so that transaction costs can be computed by the actions of the market participants, and it allows centralization of cryptocurrencies while retaining decentralized consensus of their state. The Proof of Work provider could also include other services like "smart property", not just cryptocurrencies.

Transaction fees could be calculated by a cryptocurrency in any fashion they like and offered to the miner that includes it on the Proof of Work blockchain. Miners would simply reject fees that are too low to include the cryptocurrency block on the Proof of Work blockchain. I would think cryptocurrencies would employ strategies that provide increasing fees the longer it isn't included on the Proof of Work blockchain.

I think a Proof of Work miner would need to run a full node for any cryptocurrency it's providing work for. Though the miner could choose any arbitrary combination of cryptocurrencies.


Update 5/13: Well I guess this was too stupid to consider, or else I didn't explain well enough how this is different from merge mining? What I described is almost the same as merge mining, the difference is that there is no need to pay miners in any particular cryptocurrency. In merge mining, bitcoins are required in order to pay fees, but in what I described the way the miner is paid can be in any form the miner wishes which could be bitcoins, or any other cryptocurrency, or even fiat if you wanted to do that for any reason. The only requirement to add to the Proof of Work blockchain is proof of work, aka; A hash meeting difficulty requirements.
3  Bitcoin / Mining support / Merged mining - Questions on: November 06, 2014, 03:31:52 PM
Sorry if this has been brought up before. I couldn't find a recent topic to post the question in.

Normally PoW hashes a block that contains the previous block header, in this way creating a chain of work that can be independently verified.

In merged mining, the miner is still doing the same thing, but is also checking to see if the hash happens to match what is required for the merged coin.

In the wiki it happens to shows these difficulties;
000000000000b269000000000000000000000000000000000000000000000000 -- Namecoin difficulty target
00000000000009ee5d0000000000000000000000000000000000000000000000 -- Bitcoin difficulty target

So my questions are;
1.) Is it true that merge mining is just a random shot in the dark to see if a hash matches what is needed for another cryptocurrency?
2.) Is it true that the other coin is several orders of magnitude lower difficulty than the main BlockChain for this reason?
3.) If those are true, isn't it also true that a merge-mining coin can never be anywhere near as high a difficulty as the main blockchain and therefore is much more vulnerable to a 51% attack, if miners target that coin specifically?
4  Bitcoin / Legal / CoinLenders Lawsuit on: November 17, 2013, 02:08:00 AM
Update: Since I have settled with TradeFortress for 199.383 bitcoins, I no longer have any standing in a case against him. If someone wants to take over, then please let me know and I'll point people in your direction.

With TradeFortress' alarming lack of transparency and direction, coupled with his highly suspicious actions surrounding the alleged hack on October 23rd, I've decided that I want to start legal proceedings against him.

At this time, it seems that a class action lawsuit would be most appropriate, but I am open to the idea of pressing criminal charges.

If anyone in this forum knows of a good lawyer that could handle this case competently and at a competitive price, please let me know. If you have any other relevant information or advice, kindly post it below.
5  Economy / Service Discussion / CoinLenders,, Tradefortress (HACK) on: November 08, 2013, 06:03:54 PM
What happened
On October 24rd 6:37am UTC+10:,'s hot wallet, of 4000btc, was emptied by a hacker.1 2
TradeFortress claimed the hack occurred on the 26th.3

His Linode administrative account was first accessed by the hacker on Oct 23rd, from IP Address, at 11:57am UTC+10 from Australia4.

He gained access to the account by compromising the email address "" and requesting a password reset from the Linode server. The reset link was automatically forwarded from the administrative email "" to "".5
He did not stop forwarding emails until October 27th UTC+10.5

TradeFortress reset his Linode Manager password and logged into it by 8:25pm UTC+10.4

Between 8:25pm UTC+10 and 6:37am UTC+10, Tradefortress did not shut down the site, he did not move any of the coins to a cold wallet, he did not report the theft to local authorities, he did not notify any depositors, and he did not stop any new users from depositing to his site.

Sometime after this but before second hack, TradeFortress enabled 2FA on his Linode Manager.5

On November 8th at 6:01am UTC+10, the server was hacked again using a direct Lish connection, bypassing 2FA and stealing an additional 160 bitcoins.6

By his own admission, TradeFortress was embezzling the deposits of new users to distribute the bitcoins to users that had lost their entire deposits during the hack.

TradeFortress did not have any bitcoins stored in a cold wallet either for or

CoinLenders was affected, because it had a wallet.

If you are a victim.
The following will help you to report to the proper authorities;

United States:

Goal of this thread
I would like Coinlenders users and users to post relevant information, and I would like to put together a list of users and their claims. I have requested similar documentation from TradeFortress.

I am not interested in any kind of speculation, fiction, trolling, unbacked accusations, "pity-me" stories, or any other kind of uninformative posts. They will be deleted.

Public information regarding this hack will be collated and placed here.

This is to assist in investigation, inform those at stake, perform verification and oversight, and prune useless information.

Australian law enforcement activity
TradeFortress and his hosting provider are located in Australia, and although I do not have any hard evidence to post, I am sure that Australian law enforcement has been notified.

TradeFortress' identifying information

Current plans for remuneration accounts are being refunded partial amounts inversely proportionate to the amount of BTC they had at, using a sliding scale.
As a rough estimation (see blow), deposits of over 10btc are refunded less than 50%, deposits below 10btc are refunded greater than 50%.

There has been no announcement yet regarding CoinLenders Deposits. and Coinlenders account balances.
Please send a private message to me, or post below to be added to this list. You will be anonymous unless you explicitly tell me otherwise, or post the information publicly. They will not be verified unless I can get reputable documentation (Most likely from TradeFortress).

I am including interest, because that is owed even if TradeFortress is unable to pay it.

Users will be posted as [Username]:[BTC owed]:[BTC returned]:[Unverified/Verified]

windywinter:20:20:U               <--Mistake
Dougie 12.857412:0:U
asanerworld: 1.09027010:0:U

Total Owed:6514.894239
Total Paid:219.383

simple-dice:4.21:2.58:U -No fee, unconfirmed.
quimpstar:2.785:1.69:U -Unconfirmed
GoldBit89:0.06972042:0.06:U -No fee, unconfirmed.

Total Owed: 531.4448387
Total Paid: 20


Food for thought..
I do not show this quote to imply that TradeFortress was a scammer, but that the problem that I find myself in, and how to try to avoid it, was written a year before this event took place. So I'm putting it here in case you find it as educational as I did;

This system is obviously far from perfect at the current time. For one, as it is nascent there exists the incentive to follow short term goals : build an identity up to whatever value, then strip it by taking the money and splitting. This has happened so far numerous times, and from a certain perspective it may seem the main economic activity surrounding Bitcoin at the moment, greatly compounded by the yet inept identity-valuation methods used by participants, their unwarranted self confidence (everyone thinks they’re a great judge of men, and everyone thinks their particular assumptions are both correct and warranted), their imbecillic pride manifested in the stupidest way it could, ie trying to keep “things” under wraps and all the rest of typically human failure. For the other, as it is nascent very little is in fact understood or generally known about it, and so gross mistakes happen quite cavalierly.7 -Mircea Popescu

6  Economy / Gambling / Hosting gambling site in the US is legal. on: October 11, 2013, 01:29:17 PM
So after doing a bit of research, I've found out a few things about gambling in the US.

1.) Sports betting, and the hosting of sports betting sites in the US, is illegal.

2.) Banks may not facilitate gambling in such a way as to launder money.

3.) There is no Federal law which prohibits US citizens from betting on a gambling site.

What I have not found is any federal laws which prohibits the hosting of a gambling site in the US which does not participate in sports betting, and which does not launder money.

As I have found no such law, the only logical position is that it's perfectly legal to host a gambling site in the US.

If there is a Federal law that says it's illegal to host a gambling site in the US, then I would appreciate it if someone would produce it.

The closest I have found is this;
Unlawful Internet Gambling Enforcement Act
The Act prohibits gambling businesses from knowingly accepting payments in connection with the
participation of another person in a bet or wager that involves the use of the Internet and that is
unlawful under any federal or state law
(termed “restricted transactions” in the Act).
But that begs, the question, "What is a restricted transaction?" I haven't found where that's specified, even though the term is used 36 times.

Unlawful Internet Gambling Enforcement Act
A joint rule has been issued by Treasury and the Federal Reserve Board that
designates five payment systems as covered by the Act. The designated payment
systems are: (i) automated clearing house (ACH) systems, (ii) card systems, (iii)
check collection systems, (iv) money transmitting businesses, and (v) wire
transfer systems.
I don't see how a gambling site falls under any of those categories.

7  Alternate cryptocurrencies / Altcoin Discussion / Why Ripple has failed. on: September 19, 2013, 02:41:25 PM
I was asked to create a new Thread on this subject rather than derail the other thread. So here goes nothing.

Ripple at its conception was the idea that in a web of trust debt (IOU's) can be created and destroyed among two or more parties that do not know each other.

The maximum amount that these two parties would trust each other was derived from the chain of proximate trust among a string of people between the two unknown parties. The lowest trusted amount along the chain would be assumed to be the trust between the two unknown parties.

The people in between the unknown parties are called "Liquidity Providers".

Flow of IOU
Party A -> Party B -> ... Party Z
If the lowest trust in that chain is 50 cents, then it is assumed that Party A could get an IOU from Party Z worth 50 cents and vice versa.

The name "Ripple" came from the idea that debt would be created and passed along this web in a ripple-like fashion.

This would be extremely useful because potentially the IOU's could be traded on the market without even needing to redeem them at a "Gateway". (A gateway is essentially just another party that is generally trusted and has a lot of assets. Usually a Bank.)

This would replace all of the tedious vetting, oversight, and redemption mechanisms for debt that exist today.

Almost immediately upon the acquisition of Ripple by OpenCoin, the web of trust was almost entirely destroyed because what became immediately apparent is that a trust relationship among two end parties cannot be derived from the known trust relationships among consecutive parties no matter how intuitive it might seem.

Consider your best friend. You might trust this friend with $10,000 no questions asked. How much would you trust your friends friend, no questions asked? If you're prudent, the answer would be "nothing".

However, in the ripple system, if your friend trusts his friend for $10,000 then this unknown person could borrow $10,000 from you!

Now if this person borrows from you and defaults, who's at fault? Would it be reasonable to sue your best friend because he's the one that extended trust out to this person that screwed you over? Do they share fault? This is frustrating enough, but in Ripple the defaulter could be a friend of a friend of a friend of a friend etc, and you could suddenly be out $10.00 .

I hope I've made it clear at this point that even one liquidity provider between a lender and a borrower is broken. It cannot be rationally done, and it cannot be fixed.

In order for this to work appropriately an algorithm to calculate the derived trust relationship between two unknown parties given only the trusted principle between consecutive parties in a chain would need to be formulated. Given that trust is subjective, no such algorithm can ever be formulated.

Therefore, the liquidity provider mechanism in Ripple needs to be removed entirely.

OpenCoin has not done this. Instead, no Gateways act as liquidity providers, and users are asked not to trust anyone but gateways. If a user is foolish enough to extend trust to even their best friend, they could be out real money in the aforementioned fashion.

At this point the only way OpenCoin's Ripple implementation works is if no one acts as a liquidity provider. No web of trust can exist. Therefore Ripple, as initially envisioned, has failed.

Now, even if the first impossible algorithm was formulated. There is a second fault in the Ripple system as original envisioned. The principle of a debt is not the only factor that determines the value of a debt. Initially it might seem intuitive that a $10 debt between two individuals is functionally equivalent, so that two lenders could trade their IOU's among each-other freely.

However, the value of debt in a marketplace is derived from the chance of default, the length of time the debt is held, the value of the principle, and the subjective value of a product held today versus the promise of a product at a future date.

Therefore, the value of a unit of USD IOU from Bank A and the value of a USD IOU from Bank B are different. They can not be equivalently exchanged based only on the principle.

This sounds crazy, but a quick thought experiment will prove to you that it is true.

Consider that your best friend owes you $10,000, and a your friend is owed $10,000, could you exchange the IOU's and wipe out the debt? No, because you still have to redeem the IOU's with your friends friend, which may not be good for it. You value the debt between your best friend differently than you value the debt with some person you don't know.

In summary Ripple, as was initially envisioned, failed for two reasons;

1.) No algorithm can be formulated to predict the trust relationship between two end parties given only the trust relationship among consecutive parties in the chain.

2.) The value if debt is subjectively determined. Therefore, no accurate calculation can be performed between IOU's, even if they are denominated the same underlying asset.

So that's how the original Ripple idea failed, but I will go a step further and describe why today's Ripple will not work.

Today's Ripple still holds onto the ghost of liquidity providers, but only among users (not gateways), and therefore exposes users to the risk of holding onto irredeemable IOU's in the event of a Gateway default (Or even a user default if they in-advisably trust someone other than a Gateway).
Not only are Ripple users not compensated for this risk, but Gateway will almost surely charge a premium to issue IOU's.

Think about that for a second. You go to a bank, give them money, and then receive a promise to get that same amount back from them less 1 or so percent at a future date. It's a CD with a negative return.

Not only is this perverse, but Gateways have an incentive to give out as many of these IOU's as they possibly can and then avoid redemption through any kind of contrivance that they -or their government- can dream up.

The people at OpenCoin say that this isn't a problem because the IOU's would devalue and the Gateway would not be able to sell their IOU's. This is true, but nonetheless there is a constant Moral Hazard built into the system that doesn't normally exist. (Fractional reserves are all but guaranteed.)

For the current system to work,
1.) IOU's would have to redeem for an amount higher than the principle. (I can't think of any way to do that besides introducing a Minimum-Held time to IOU's)
Edit: If users can't be Liquidity Providers, the above might not be necessary for some assets, given the utility gained by being able to exchange the IOU's.
2.) The final nail needs to be put in the coffin of "Liquidity Provider". (It should be removed entirely.)

While those problems are not unsolvable, they are tremendous tasks that are burdened by the cost of XRP, and it ensures only limited liquidity on the system.

Instant redemptions on this Ripple system are a fantasy. Edit: That's not really claimed anyway.

Now. If those problems are solved, Ripple will be an open source, trust-based, free to enter system for the trading of CD's denominated in any arbitrary asset (currencies/stores of value). Cool.
The great thing about that is any currency can be exchanged if the user base is big enough, without the need of Gateways to hold onto any IOU's of other Gateways.
For instance, you could trade a XBT IOU with a ripple user for a USD IOU, and then redeem the USD IOU at the USD Gateway, which doesn't care at all that you originally had a XBT IOU.

Edit: Expanded the explanation of the benefits of a working "quasi-ripple".

Excellent objections can be found here;
8  Other / Beginners & Help / BitEnsure (Latest Ponzi Scheme) on: August 05, 2013, 01:51:43 PM
Hi Everyone! I hope just because this is a noobie post that this doesn't get overlooked, but this was just too precious for me to leave to myself.

Without further ado.
Suspicious crap concerning "bitensure";

They have one listed employee without a full name; "David DV", and his email goes to some mysterious black site called
It's beyond "damned weird" for a business to use a website for their email that is separate from either their company (bitensure) or even their parent company (metaneural).

Their "We Are Hiring!" button does nothing.

None of their "read more" buttons work on the front page. (In the presentation doohickey..)

The image of said, "David DV" is a stock photo. Just one example can be found on

(I highly doubt that he/they own "Suite 600" at 8400 East Crescent Pkwy Greenwood Village, CO 80111.)

Metaneural was first registered on: Feb 04, 2013
bitensure was first registered on: July 21, 2013

Unlikely that a business that registered its domain name 6 months ago (metaneural) is some super successful business. It also suffers from the same Mysterious Owner Syndrome that we have at

Randomly decided to reduce their rates (I heard that it was because of the litigation with pirateat40, but that was going on even before their first "offering");

In short, if you gave them bitcoins, get them back.

Side note; bitensure is offering interest on the bitcoins themselves, not the dollar value. So the speculation from the dude at cryptocointalk about bitcoin's price rising faster than the interest is impossible.
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!