Bitcoin Forum
December 08, 2016, 09:59:08 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Poll
Question: Will you support Gavin's new block size limit hard fork of 8MB by January 1, 2016 then doubling every 2 years?
1.  yes
2.  no

Pages: « 1 ... 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 [1193] 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 ... 1560 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 1806136 times)
tvbcof
Legendary
*
Offline Offline

Activity: 1988


View Profile
May 11, 2015, 01:23:57 AM
 #23841


Yes, I was imagining using IBLT to maybe provide a mechanism to allow for some kind of parallelization of the nodes, so that each node only needs to contain a small chunk of the UTXO data.

I guess what I'm envisioning is a node structure where it might be possible to split up the work of maintaining the blockchain similar to how storj is fragmenting and distributing files.

Any proposed solutions I've seen so far to the scaling issue have been incremental at best, so I want to start spitballing some more "outside the box" crazy proposals, but I'm not a programmer so I only have a rudimentary idea of what's feasible.

Sorry if it's all just a waste of time.

Not a waste of time, but it's true that the idea of sharding is about the first thing that pops into anyone's head since it is a go-to solution for such problems in many domains.  A problem with it as a solution to scaling problems of the block chain is that the UTXO set is real-time (whereas a block chain is batch mode) and one needs to keep a real-time eye on the stream in order to avoid being scammed (or suck it up and wait for a sufficient number of blocks to be cemented in by others.)  And, if one is already keeping an eye on a real-time stream one may as well retain the stream which gives one a whole blockchain anyway.

So-called 'treechains' seems to offer some possibility to do what I would conceptualize as 'longitudinal sharding'.  Using something like a btree logic to retain transaction chains in a longitudinal shard ('fiber'?) might be one something that could have worked and still allowed distributed system support.  That would have been interesting, but that bird had flown at the same time Satoshi made his announcement on the mailing list as I see it.

Subordinate chains (which was my word for sidechains from when I first got interested in 2011) seem to be a serviceable solution which solve the scaling problems in a very simple and effective manner.  A little crude-ish and thus not as sexy as treechains and like sharding, but that simplicity  in and of itself is confidence inspiring to me.  A very notable side benefit is the isolation from core Bitcoin which allows many different solutions to be tuned to many different problems.  Relatedly, it allows many more people and entities to become stakeholders in, and potential supporters of, Bitcoin's health.  I like that very much.

---

On a different topic (as cypherdoc says), the first thing I thought of when I read up on IBLT's is that they could be a marvelously efficient way to communicate info needed to ensure that transaction blocks were correctly formed in a number of ways.  One biggie would be that they contained only 'authorized' transactions and/or did not contain 'unauthorized' ones.  Such a thing would be necessary and necessarily efficient in order to implement whitelisting or blacklisting.  To this day I have seen nobody comment about this (potential) 'feature' of such a development.


1481191148
Hero Member
*
Offline Offline

Posts: 1481191148

View Profile Personal Message (Offline)

Ignore
1481191148
Reply with quote  #2

1481191148
Report to moderator
1481191148
Hero Member
*
Offline Offline

Posts: 1481191148

View Profile Personal Message (Offline)

Ignore
1481191148
Reply with quote  #2

1481191148
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481191148
Hero Member
*
Offline Offline

Posts: 1481191148

View Profile Personal Message (Offline)

Ignore
1481191148
Reply with quote  #2

1481191148
Report to moderator
1481191148
Hero Member
*
Offline Offline

Posts: 1481191148

View Profile Personal Message (Offline)

Ignore
1481191148
Reply with quote  #2

1481191148
Report to moderator
solex
Legendary
*
Offline Offline

Activity: 1078


100 satoshis -> ISO code


View Profile
May 11, 2015, 01:30:13 AM
 #23842

An attack I thought of years ago would be to formulate UTXO's systematically to chain blocks together in such a way that 1) their count would stress the working database (currently implemented in RAM most often) and 2) verifying them would touch as many blocks as possible making rendering of much of the actual blockchain itself require for many transactions.  I'm sure there is a name for such an attack.  If not, call it the 'tvbcof attack' I suppose.

Something like this was brought up on reddit. Why not have higher fees for these kind of "tvbcof transactions"? (Higher fees in proportion to how much they scatter the UTXOs. And perhaps lower or zero fees for transactions that consolidate UTXOs.)

A spotlight has gone onto the UTXO because it is bloating, e.g.

FWIW, here are a few observations related to the growth of the utxo set.

The growth rate of the utxo set has increased since late 2013 / early 2014.

More interestingly, a repeated pattern has appeared since early 2014, showing steps every sunday (around 100k utxos added to the set every sunday).



My bold emphasis.

Gavin has kicked over the card-table by writing his 20MB patch and going public with it. There is now a phenomenal amount of constructive debate going on in dev, particularly around ideas like leveraging an increased block limit for maintaining a cleaner utxo set and an improved fees market by paying for extra block space.
Interesting that the market is looking more bullish since Gavin's announcement than a long while previously.

The drawn line extrapolates based on an assumption of linear growth from some point midway along the function into the future.
If we drew a linear line from the start of the dataset through the current time, we would hit 20MB at a different, earlier date.
If we drew the line of best fit as a polynomial function (which is currently above the line and returning to it), we would hit 20 MB at a different, still earlier date.
If we drew a sigmoid function where we are approaching a ceiling, it is possible that limit would never hit 20MB.

If it is within anyone's capacity, I think it would be worth throwing these data points into some statistical software and determining line(s) of best fit, with correlations and such.
It would turn something that is subjectively interpretible into something objective.
I think that's important in this debate, for many of the reasons Zangelbert mentioned above.



Agreed, but the projection which Peter has is probably as good as any other fit. Some considerations:

The volatility in 7-day average block size has collapsed since 2010 and would imply a maturing process of the ecosystem. Arguably, the phase up to mid-2012 was primarily usage from "innovators" and since then "early adopters", which continues today. Projecting forward from mid-2012 data would seem more realistic for predicting the near future.

The "bump" from April 2012 to March 2013 is basically the effect of SatoshiDice which doubled the transaction loading until its owner (Eric Voorhees) modified it, and Core Dev changed dust thresholds.

Transaction size has doubled since 2012 from about 250 to 500 bytes (hence the oft-quoted max throughout of 7tps is more like 3tps), largely because of scripting and multisig. Without this the average block data would look more sigmoid. Adam Back suggests that off-chain tx is already 100x on-chain (e.g. including exchange volume etc), and he is probably right. Lighting Networks, Coinbase and the like, could eventually take so much off-chain volume that indeed, the 20MB may not be reached until well after 2021.

TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
May 11, 2015, 02:01:16 AM
 #23843

I think we should also re-summarize whether pool control can be defeated by the new pool RPC (was it "getblockdata"?) that allows the miner to add or remove transactions. I must admit it has been a while since I looked at that and I might not have completely digested it (in a rush or whatever).

Perhaps someone can chime in so I don't have to go google it.

https://bitcoin.org/en/developer-guide#getblocktemplate-rpc

it's getblocktemplate and i've already pointed out that it gives miners the flexibility to construct their owns blocks.  as a former miner, moving to a new pool is one click away and all of us were watching carefully for any pool operators acting suspicious

I will reintroduce my point from 2013, that you all won't be mining in the future, because the cartels can (in the future) make mining unprofitable for you with the Transactions Withholding Attack. Many of you can't seem to grasp that attack properly, so I am not relying on that to make my argument below. Yet I maintain that the Transactions Withholding Attack is another future reason that Bitcoin mining will become entirely centralized by the banksters. Note the obvious that in the future all mining income will come from tx fees.

However does it really give control the miner? I don't think so. The users still need to forward transactions into the network and eventually the volume of transactions will be too great for miners to listen to and compare with what the pool is sending them. They will at some point be forced to delegate transaction compilation to the pools.

you'll need to give a citation on this.  i'm not aware of any problems with loading the size of the unconfirmed tx's data set into RAM at all on startup.  in fact, the set is fairly uniform across all nodes b/c of the speed of the network which allows proposals like IBLT from Gavin a chance to be implemented.  i've never heard about any concerns going forward on this.

At Visa scale (e.g. 8000 txs/sec) this is no problem. But at micropayments txs scale, i.e. billions of txs per second, the individual miners don't want to duplicate the connectivity and processing power infrastructure necessary to handle that volume of txs.

If the micropayments txs will be handled by an off-chain layer, then perhaps that aspect of my point does not apply. I will study more the off-chain proposals and get back to you this point.

I don't think IBLT can work (afair perhaps I explained my stance in my refutation of Peter Told at afair the Git hosted IBLT paper), but that is apparently OT the main point of discussion herein.

In any case, I have another argument against the intended efficacy of getblocktemplate. Again remember my concern is about a Digital Kill Switch, wherein rarely an individual's number has been shut off and they are not allowed to transaction (for political persecution or whatever), thus these will be rare occurences. So the pools can simply discard and ignore block solutions that insert such excluded transactions. Miners will have a difficult time winning political will over such rare instances. For example, if the miners move to another pool that has an established reputation of never doing this, the banksters can attack that pool by numerous means (e.g. shutting of their regulatory license, Meni's Share Withholding Attack, out-of-band social, political, and economic attacks, etc). Eventually the banksters can force you to their Sybil attacking pools (you never know which one is legit as they will change as soon as you try to Whack-A-Mole).

I am sorry. You can't win this political battle. Because the banksters will have the masses on their side. The masses are complacent and they will stick with what ever miners and pools that Amazon.com directs theirs their txs to.

You can not win this way. It is so obvious. Think it out. Even Satoshi said the mining would be controlled by corporations in the future.

thezerg
Legendary
*
Offline Offline

Activity: 1246


View Profile
May 11, 2015, 02:04:04 AM
 #23844


Wink its a puzzle and you took the expected path into the maze and that is why you did not solve it. Epiphanies are like that. Yes I will have to elaborate but I am not going to give away such a valuable insight for free. I'd rather implement and profit. Wouldn't you?

No actually.  trying to get seed capital and forming a startup is the wrong approach if you really want to make a difference.  Otherwise pressure for corporate profits will poison the coin.  And the ability of external entities to apply pressure to a corporate entity (see Ripple) could destroy it.  

Publish your insight for the rep, good jobs will follow.

Also if you aren't going to describe your ideas, don't gloat about them endlessly -- there is no information content in most of your posts.

Since you are not sharing your ideas and consider that we are not intelligent enough to contribute to them, I think you should ask yourself why you bother posting at all.  What do you get out of it?  Wouldn't your time would be better spent implementing your ideas?  You need help seeing yourself...

And finally, you might consider that many people here are fighting great hardship yet you will likely not know about it until you read their "so long and thanks for all the fish" post.  I am sorry that you do not have others, closer to you to share these troubles.  Today I heard a sermon about a guy who could wish for anything so he imagined a luxury mansion, cars, gourmet food and the like... and he ended up with what he wished for -- an empty house.  Maybe you should start by sharing here to fill that house.  Check out http://www.reddit.com/r/raisedbynarcissists/ it may help you.
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
May 11, 2015, 02:19:19 AM
 #23845


Wink its a puzzle and you took the expected path into the maze and that is why you did not solve it. Epiphanies are like that. Yes I will have to elaborate but I am not going to give away such a valuable insight for free. I'd rather implement and profit. Wouldn't you?

No actually.  trying to get seed capital and forming a startup is the wrong approach if you really want to make a difference.  Otherwise pressure for corporate profits will poison the coin.  And the ability of external entities to apply pressure to a corporate entity (see Ripple) could destroy it.

That is why I only want to deal with 1 - 3 individual investors who are altruistic and want to get possibly rich on their investment.  

Publish your insight for the rep, good jobs will follow.

Interesting point. Don't you think it would be more fun to get rich at the same time of saving the world? Unrealistic maybe. I am evaluating.

I feel I am a person who could do much great things for the world with capital. I think the universe should entrust large capital with me. Perhaps I am mistaken. I am evaluating.

Also if you aren't going to describe your ideas, don't gloat about them endlessly

Fair enough. I won't mention my solution again then. No additional hints will be given then. Satisfied?

-- there is no information content in most of your posts.

Obviously false. Please retract the emotional statement.

Since you are not sharing your ideas and consider that we are not intelligent enough to contribute to them

I did not say you are not intelligent enough. Your username rings a bell and I haven't looked, but I seem to recall you are person of significance in the development of Bitcoin (or Scala?). Perhaps I am mistaken. So far, your posts have been interesting to me and I am preparing to look at your latest idea and either mea culpa or refute it.

, I think you should ask yourself why you bother posting at all.  What do you get out of it?  Wouldn't your time would be better spent implementing your ideas?  You need help seeing yourself...

Perhaps because I like to see you get all ego twisted like this?

Naw. Rather I am trying to point out what is futile and get some interest to invest in my solution. Isn't that obvious enough?

And finally, you might consider that many people here are fighting great hardship yet you will likely not know about it until you read their "so long and thanks for all the fish" post.

I know some of them and they know I empathize with them. I can't empathize with those who haven't told me.

I only reacted with my personal plight due to the disingenuous attempts to character assassinate me when the antagonists had lost the logical point (or simply didn't pay attention because they wanted to attack me).

If the discussion stays on technicals and civility, then so do I.

I don't know what to do about the fact that you don't agree that I don't give my ideas away for free in every instance. I guess you demand I be a Communist. And I an reticent. I am evaluating what is the wisest way to proceed.

I am sorry that you do not have others, closer to you to share these troubles.  Today I heard a sermon about a guy who could wish for anything so he imagined a luxury mansion, cars, gourmet food and the like... and he ended up with what he wished for -- an empty house.  Maybe you should start by sharing here to fill that house.  Check out http://www.reddit.com/r/raisedbynarcissists/ it may help you.

Well so we see that your entire post was a yet another jealous veiled character assassination against all those who are reticent to Communism and groupthink.

Kudos.  Roll Eyes (wasting more of our time)

solex
Legendary
*
Offline Offline

Activity: 1078


100 satoshis -> ISO code


View Profile
May 11, 2015, 02:35:13 AM
 #23846

On a different topic (as cypherdoc says), the first thing I thought of when I read up on IBLT's is that they could be a marvelously efficient way to communicate info needed to ensure that transaction blocks were correctly formed in a number of ways.  One biggie would be that they contained only 'authorized' transactions and/or did not contain 'unauthorized' ones.  Such a thing would be necessary and necessarily efficient in order to implement whitelisting or blacklisting.  To this day I have seen nobody comment about this (potential) 'feature' of such a development.

I can put your mind at rest there.
What you describe as "authorized" is really "50+% consensus", i.e. that an unconfirmed transaction is acceptable by the majority of nodes.
Consider the existing blockchain. It is full of confirmed tx which were accepted by at least 50+% of the hashing power. There were many orphan blocks which a minority of nodes might have accepted, but were discarded by the majority.

One of the powerful aspects of IBLT is that it creates consensus on unconfirmed tx. It makes the Bitcoin protocol function more closely to how all its users expect it to work.

Right now there are several thousand users who expect their transaction(s) to get confirmed in the next block, and thousands of nodes who have a very similar view of those transactions. Usually, miners are good citizens and include many of the pending transactions. However, a block could be mined where all this consensus is ignored and the new block is full of transactions which the miner has "pulled out of his ass" (real-world business or not) with fees payable to himself. Apart from providing PoW security to older blocks, the new block is unhelpful, and many of them together is an attack.

So the "unauthorized" transactions are simply those that are already missing from the majority of the network's node mempools. The reason they are missing is that they have been discarded by most nodes, or never seen by them because the miner kept them quiet until finding a block.

There is no whitelisting or blacklisting unless 51% of the nodes are using the same whitelist or blacklist. If they are then there then that is a majority decision, and the risk of this is the same as today.
Also, standard new blocks with full tx would certainly remain supported even if IBLT was fully functional and in widespread use.

tvbcof
Legendary
*
Offline Offline

Activity: 1988


View Profile
May 11, 2015, 02:35:52 AM
 #23847

An attack I thought of years ago would be to formulate UTXO's systematically to chain blocks together in such a way that 1) their count would stress the working database (currently implemented in RAM most often) and 2) verifying them would touch as many blocks as possible making rendering of much of the actual blockchain itself require for many transactions.  I'm sure there is a name for such an attack.  If not, call it the 'tvbcof attack' I suppose.

Something like this was brought up on reddit. Why not have higher fees for these kind of "tvbcof transactions"? (Higher fees in proportion to how much they scatter the UTXOs. And perhaps lower or zero fees for transactions that consolidate UTXOs.)

A spotlight has gone onto the UTXO because it is bloating, e.g.

...

I would phrase things "A spotlight has gone onto UTXO because they are bitcoins."  Nothing comes closer to an accurate explanation to what a bitcoin is in my opinion.

I would take issue with the idea that 'UTXOs are bloating.'  They are doing so to a much lesser degree than I would have imagined years ago.  The reason for this, I believe, is that off-chain work has come to the rescue (in the ugly form entities with counter-party risk for the most part and the associated thefts that come with such) and many many BTC are tucked away into deep storage as the equivalent of $100,000,000 bills UTXO-wise.  That is the genie which comes out of the bottle when you guys realize your dream of a one-size-fits-all everything-to-everyone exchange currency for the masses.  Not sure if you are still in that camp solex...you seem a little more bright or flexible or something than most here.


TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
May 11, 2015, 02:36:51 AM
 #23848

One of the powerful aspects of IBLT is...

IBLT is pie-in-the-sky that won't work. I studied it. I elaborated somewhere. I will have to dig for it and refresh my memory.

thezerg
Legendary
*
Offline Offline

Activity: 1246


View Profile
May 11, 2015, 02:43:31 AM
 #23849

I don't know what to do about the fact that you don't agree that I don't give my ideas away for free in every instance. I guess you demand I be a Communist. And I an reticent. I am evaluating what is the wisest way to proceed.

No man, I am certainly demanding nothing of you, and am the last to desire Communism.  This is a strategy to actually maximize your returns.  Look at current altcoins; if you or your investors poison your coin you'll get nothing.  If you do not poision it, you and a small number of people will be the first to mine the next new thing and you may actually get help implementing it -- help which seems to be needed because haven't you been talking about this for over a year now?

I am sorry that you do not have others, closer to you to share these troubles.  Today I heard a sermon about a guy who could wish for anything so he imagined a luxury mansion, cars, gourmet food and the like... and he ended up with what he wished for -- an empty house.  Maybe you should start by sharing here to fill that house.  Check out http://www.reddit.com/r/raisedbynarcissists/ it may help you.

Well so we see that your entire post was a yet another jealous veiled character assassination against all those who are reticent to Communism and groupthink.

Kudos.  Roll Eyes (wasting more of our time)

Please consider my possible reasons for "jealous veiled character assassination".  Look at my post history to see if I'm a troll.  I have none of these motivations.  Consider that you applied a pejorative -- a negative emotional reaction -- to the idea of narcissism, not me.  Consider that you always manage to get into these endless ad hominem postings, not me.   I'm actually trying to help you where I think you most need help; read some of those posts. How are you similar?  How are you different?

But that will be all I say or read on this subject; by the time I read this thread next these messages will be buried too deeply for me to see.






cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
May 11, 2015, 02:47:01 AM
 #23850

So that is one argument that can be made against the pool's having control. Note it doesn't impact my other upthread (and very on topic) point that larger blocks favor centralization because higher orphan rates do.

larger bloat blocks have a higher chance of being orphaned

I reiterate my upthread point that higher orphan rate favors larger pools because they will be better connected (don't forget the NSA has direct taps on major trunk lines and the high-speed traders on Wall Street have this superior connectivity too) and thus mine on orphaned chains less, thus have high profits for their miners, thus driving more miners to them and making the smaller pools go bankrupt. This is a variant of the selfish mining effect.

Thus I will repeat again that larger blocks = centralization.

I hope that is clear now, since apparently you didn't get it the first time and apparently ignored or didn't understand me?

(if you did ignore before, covering your ears won't help you)

My radical re-design totally eliminates the issue of orphans and the critical advantages of connectivity latency. It is a radical paradigm shift that solves the problem that Bitcoin was designed to be centralized and there is nothing you can do within Bitcoin's current design to stop that! (I will elaborate soon)

Add: and the key point of distinction is that in Bitcoin in order to get a transaction to have a confirmation then it must be put into a block. In my novel new design, transactions don't have to be put in blocks in order to be confirmed. That is a very strong head scratching hint for you!

well that'll be a trick b/c the blockchain is Satoshi's fundamental contribution to tx security that was missing for all these decades of digital money formation.  each block cements the tx's into the chain via POW.  

you need to elaborate on your purported innovation to have any meaningful discussion.

Wink its a puzzle and you took the expected path into the maze and that is why you did not solve it. Epiphanies are like that. Yes I will have to elaborate but I am not going to give away such a valuable insight for free. I'd rather implement and profit. Wouldn't you?

You'd be crazy not to invest.

Yes it is a trick. The key insight is into how to make things orthogonal with a clever twist. I must admit, the more I think about it, the less obvious it is. I do have the antithetic weakness of the Dunning-Kruger syndrome, "Conversely, highly skilled individuals tend to underestimate their relative competence, erroneously assuming that tasks which are easy for them are also easy for others.".

For $10,000 investment and promise of secrecy, you can find out now.

Note my Bitmessage is not functioning on my new ISP, so anyone that wants to talk with me should PM me then we will go into encrypted webchat (very easy just load a webpage and chat).

as i was talking about IBLT above, if we get that implemented according to Gavin's proposal, that would eliminate your theoretic large pool "improved connectivity" advantage.  
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
May 11, 2015, 02:59:50 AM
 #23851

as i was talking about IBLT above, if we get that implemented according to Gavin's proposal, that would eliminate your theoretic large pool "improved connectivity" advantage.  

Indeed. But technically it won't work. I don't have time to go into that today, but I will soon. Even Gavin has admitted there are yet unresolved problems. I haven't been following it lately, so I will need to go and dig back into it. But again, not today. I am already behind schedule today.

And even if IBLT works, it can't address the Transaction Withholding Attack nor the point I made about getblocktemplate being impotent against the complacency of the masses.

And the other problem is IBLT may never be able to be deployed. Hard forks are political hurdles. This will be a huge one.

P.S. afaik Gavin has never designed something significant for Bitcoin. All the major stuff was decided before Satoshi left. Correct me if I am mistaken.

Peter R
Legendary
*
Offline Offline

Activity: 938



View Profile
May 11, 2015, 03:29:29 AM
 #23852

And the other problem is IBLT may never be able to be deployed. Hard forks are political hurdles. This will be a huge one.

Can you explain why adding IBLT support would be a hard fork?

Run Bitcoin Unlimited (www.bitcoinunlimited.info)
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
May 11, 2015, 03:30:08 AM
 #23853

I believe I know how to solve that.  There are 3 innovations that form the core of a microtxn coin -- a problem I've been keen to solve because like I said years ago i think there are room 4 3 coins:
BTC: first mover for holding and large txns.
AnonCoin: maybe MRO
MicroCoin: undefined.

The 3 innovations are:
1. UTXO oriented protocol and storage.  (Merkle UTXO trees that I discussed previously)
2. UTXO size consolidation.  There are various approaches.  The previously mentioned idea for addtl fees if outputs > inputs is not quite there.  Better is addtl fee for every not-previously seen address and UTXO merkle is changed to be address-with-balance merkle tree.  Other ideas are to make address creation expensive (like vanity addresses) and address consolidation txn gets fee rebate.
3. Transformation of blockchain to scale.

What was the upthread name and link to Russel's (recently hired by Blockstream sheesh I can remember that but not the name) summary of the off-chain proposal ("lighting" something) for real-time transactions employing a payment channel (you dedicate some BTC to a particular recipient which you can dole out in real-time)?

Some real-time txs are micropayments and some micropayments are real-time, but not all real-time txs are micropayments and not all micropayments are real-time. Thus you are addressing an orthogonal need to scale the blockchain for higher tx volume.

Recall upthread one of my several reasons for stating that getblocktemplate will lose efficacy is because miners won't be able to process a million or billion txs per second.

What do you mean by point #3?

Afaics, it appears you are proposing to compress the UXTO, but you are not addressing the scaling problem. (Bounded) compression doesn't solve scaling (they are different complexity levels).

The only solution for microtxns that scales is to remove the UXTO entirely! (You've said you are not restricting me from mentioning my solution, so I mention it again!)

Anyway hoping to lay out my microcoin in a doc soon but I can't wrap my head around how to play nice with bitcoin... sidechain altcoin etc... what would you guys do?

The solution is going to be so radically different, I don't think it is going to work as a side or merge-mined chain. But I reserve final judgment after working through all the finer details.

tvbcof
Legendary
*
Offline Offline

Activity: 1988


View Profile
May 11, 2015, 03:31:04 AM
 #23854

On a different topic (as cypherdoc says), the first thing I thought of when I read up on IBLT's is that they could be a marvelously efficient way to communicate info needed to ensure that transaction blocks were correctly formed in a number of ways.  One biggie would be that they contained only 'authorized' transactions and/or did not contain 'unauthorized' ones.  Such a thing would be necessary and necessarily efficient in order to implement whitelisting or blacklisting.  To this day I have seen nobody comment about this (potential) 'feature' of such a development.

I can put your mind at rest there.
What you describe as "authorized" is really "50+% consensus", i.e. that an unconfirmed transaction is acceptable by the majority of nodes.
Consider the existing blockchain. It is full of confirmed tx which were accepted by at least 50+% of the hashing power. There were many orphan blocks which a minority of nodes might have accepted, but were discarded by the majority.

One of the powerful aspects of IBLT is that it creates consensus on unconfirmed tx. It makes the Bitcoin protocol function more closely to how all its users expect it to work.

Right now there are several thousand users who expect their transaction(s) to get confirmed in the next block, and thousands of nodes who have a very similar view of those transactions. Usually, miners are good citizens and include many of the pending transactions. However, a block could be mined where all this consensus is ignored and the new block is full of transactions which the miner has "pulled out of his ass" (real-world business or not) with fees payable to himself. Apart from providing PoW security to older blocks, the new block is unhelpful, and many of them together is an attack.

So the "unauthorized" transactions are simply those that are already missing from the majority of the network's node mempools. The reason they are missing is that they have been discarded by most nodes, or never seen by them because the miner kept them quiet until finding a block.

There is no whitelisting or blacklisting unless 51% of the nodes are using a whitelist or blacklist. If they are then there then that is a majority decision.
Also, standard blocks with full tx would certainly remain supported even if IBLT was fully functional and in widespread use.

That does not particularly put my mind to rest.

I am concerned about 'consensus' being an AND operation involving protocol legality and political legality.

Implementationally, if unconfirmed transactions are time sequence ordered, it would be practical to build a work set as a checkmarked list of legal transactions in forming work units (to be distributed if one is running a pool or ground on if one is mining within one's own farm.)  This could be accomplished more efficiently if with an system like IBLT to communicate with a tainting authority.  The miner and the tainting authority would only need to communicate the out-of-bounds transactions and the count of these could be fairly small...at least initially...

I should think also that legal transactions which took some time to verify (within the taint authority's system) could be grouped as a initial chunk onto the next block.  A side-channel could transmit this list (for a fee) to miners who are clients.  With miners operating at the pleasure of the state and compelled to utilize the services of a chartered tainting authority in order to protect us and our children from ISIS and such, the tainting authority(s) with a charter should not lack for business.


TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
May 11, 2015, 03:33:09 AM
 #23855

And the other problem is IBLT may never be able to be deployed. Hard forks are political hurdles. This will be a huge one.

Can you explain why adding IBLT support would be a hard fork?

If it is not, I mea culpa. I will need to go dig back into what I concluded about IBLT and I decided not to comment further on IBLT today so I don't say something stupid. I remember I saw a flaw that had to do with the assumption about small set differences and the proposed use of the invertible bloom filter or something like that. I forget exactly. Will dig in soon...

cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
May 11, 2015, 03:33:34 AM
 #23856

as i was talking about IBLT above, if we get that implemented according to Gavin's proposal, that would eliminate your theoretic large pool "improved connectivity" advantage.  

Indeed. But technically it won't work. I don't have time to go into that today, but I will soon. Even Gavin has admitted there are yet unresolved problems. I haven't been following it lately, so I will need to go and dig back into it. But again, not today. I am already behind schedule today.

And even if IBLT works, it can't address the Transaction Withholding Attack nor the point I made about getblocktemplate being impotent against the complacency of the masses.

And the other problem is IBLT may never be able to be deployed. Hard forks are political hurdles. This will be a huge one.

P.S. afaik Gavin has never designed something significant for Bitcoin. All the major stuff was decided before Satoshi left. Correct me if I am mistaken.

we have no proof that large pools are directly connected more so or to the disadvantage of small pools.  you haven't even given a definition of both.  but even assuming that they are, which i'm not, i've still given plenty of reasons why they shouldn't want to create attacking bloated blocks to try and torment smaller miners. 
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
May 11, 2015, 03:39:00 AM
 #23857

as i was talking about IBLT above, if we get that implemented according to Gavin's proposal, that would eliminate your theoretic large pool "improved connectivity" advantage.  

Indeed. But technically it won't work. I don't have time to go into that today, but I will soon. Even Gavin has admitted there are yet unresolved problems. I haven't been following it lately, so I will need to go and dig back into it. But again, not today. I am already behind schedule today.

And even if IBLT works, it can't address the Transaction Withholding Attack nor the point I made about getblocktemplate being impotent against the complacency of the masses.

And the other problem is IBLT may never be able to be deployed. Hard forks are political hurdles. This will be a huge one.

P.S. afaik Gavin has never designed something significant for Bitcoin. All the major stuff was decided before Satoshi left. Correct me if I am mistaken.

we have no proof that large pools are directly connected more so or to the disadvantage of small pools.  you haven't even given a definition of both.  but even assuming that they are, which i'm not, i've still given plenty of reasons why they shouldn't want to create attacking bloated blocks to try and torment smaller miners.  

The government (NSA, CIA, DEEP STATE, banksters) has the incentive and the capability.

Did we forget who the enemy is?

We need a more anti-fragile (simplified!), resilient and robust protocol that is immune to all this fragile complexity (IBLT, latency, etc).

cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
May 11, 2015, 03:42:11 AM
 #23858

I reiterate my upthread point that higher orphan rate favors larger pools because they will be better connected (don't forget the NSA has direct taps on major trunk lines and the high-speed traders on Wall Street have this superior connectivity too) and thus mine on orphaned chains less, thus have high profits for their miners, thus driving more miners to them and making the smaller pools go bankrupt. This is a variant of the selfish mining effect.

Thus I will repeat again that larger blocks = centralization

you do realize this view directly contradicts current behavior?  large miners do not build 1MB blocks repeatedly and instead construct the smallest blocks possible to limit latency transmission across the network.  if all "large" miners were hooked up as directly as you imply, they should today be constructing 1MB to maximize fees and try and torment small miners.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
May 11, 2015, 03:43:47 AM
 #23859

as i was talking about IBLT above, if we get that implemented according to Gavin's proposal, that would eliminate your theoretic large pool "improved connectivity" advantage.  

Indeed. But technically it won't work. I don't have time to go into that today, but I will soon. Even Gavin has admitted there are yet unresolved problems. I haven't been following it lately, so I will need to go and dig back into it. But again, not today. I am already behind schedule today.

And even if IBLT works, it can't address the Transaction Withholding Attack nor the point I made about getblocktemplate being impotent against the complacency of the masses.

And the other problem is IBLT may never be able to be deployed. Hard forks are political hurdles. This will be a huge one.

P.S. afaik Gavin has never designed something significant for Bitcoin. All the major stuff was decided before Satoshi left. Correct me if I am mistaken.

we have no proof that large pools are directly connected more so or to the disadvantage of small pools.  you haven't even given a definition of both.  but even assuming that they are, which i'm not, i've still given plenty of reasons why they shouldn't want to create attacking bloated blocks to try and torment smaller miners.  

The government (NSA, CIA, DEEP STATE, banksters) has the incentive and the capability.

Did we forget who the enemy is?

i don't believe large miners = NSA, CIA, DEEP STATE, banksters
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
May 11, 2015, 03:47:47 AM
 #23860

I reiterate my upthread point that higher orphan rate favors larger pools because they will be better connected (don't forget the NSA has direct taps on major trunk lines and the high-speed traders on Wall Street have this superior connectivity too) and thus mine on orphaned chains less, thus have high profits for their miners, thus driving more miners to them and making the smaller pools go bankrupt. This is a variant of the selfish mining effect.

Thus I will repeat again that larger blocks = centralization

you do realize this view directly contradicts current behavior?  large miners do not build 1MB blocks repeatedly and instead construct the smallest blocks possible to limit latency transmission across the network.  if all "large" miners were hooked up as directly as you imply, they should today be constructing 1MB to maximize fees and try and torment small miners.

We can conclude that large pools today are possibly not yet co-opted (compromised, controlled) by the DEEP STATE and we have no evidence of them doing an active attack.

That tells us nothing about the future.

i don't believe large miners = NSA, CIA, DEEP STATE, banksters

Where there is a vacuum, entropy will flow. That is an undeniable fact of the Second Law of Thermo.

Pages: « 1 ... 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 [1193] 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 ... 1560 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!