Bitcoin Forum
July 23, 2019, 08:19:57 AM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
   Home   Help Search Login Register More  
Poll
Question: You have an Active Node Full Time ?
24/7 - 20 (39.2%)
12/7 - 1 (2%)
A few hours a day - 4 (7.8%)
Never - 10 (19.6%)
In the future maybe - 10 (19.6%)
It is not of your interest - 6 (11.8%)
Total Voters: 51

Pages: « 1 2 3 4 [5] 6 7 »  All
  Print  
Author Topic: How Many Full Nodes Bitcoin Online ?  (Read 16181 times)
Lannie25
Full Member
***
Offline Offline

Activity: 378
Merit: 100


View Profile
December 29, 2018, 02:23:59 PM
 #81

There plenty in the internet it you will browse it.
The one thing good about it is that it serves a secuirty to validate some transactions and blocks other nodes which is suspicious.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1563869997
Hero Member
*
Offline Offline

Posts: 1563869997

View Profile Personal Message (Offline)

Ignore
1563869997
Reply with quote  #2

1563869997
Report to moderator
1563869997
Hero Member
*
Offline Offline

Posts: 1563869997

View Profile Personal Message (Offline)

Ignore
1563869997
Reply with quote  #2

1563869997
Report to moderator
1563869997
Hero Member
*
Offline Offline

Posts: 1563869997

View Profile Personal Message (Offline)

Ignore
1563869997
Reply with quote  #2

1563869997
Report to moderator
franky1
Legendary
*
Offline Offline

Activity: 2450
Merit: 1451



View Profile
December 29, 2018, 02:27:26 PM
Last edit: December 29, 2018, 10:36:45 PM by franky1
 #82

Also it seems to me that in any case minisketch has nothing to do about that because the drop of the tx's due to not meeting the min relay criteria is a previous step in the protocol. Minisketch just adds an optional and more efficient (bandwidth wise) way of dealing with a preexistent situation.
....

Sorry if I have stepped into this conversation without the necessary knowledge but, at this point, it has caught some of my attention and would like to know if I got it or not.

im against features that get offered as solving big picture issues but end up not solving the big picture issues of what the initial feature intent is
but devs avoiding the obvious more simple way to solve an issue network wide for everyone

EG segwit. offered as solution to malleation.. result people still are victimised by malleation after segwit activation
because the victim is not part of the choice to choose to malleate or not of funds it gets/doesnt get.
EG funny part. after pretending malleation is solved. they introduce RBF to actually help malleators malleate

as for the tx transmission bandwidth and the compact block big picture surrounding a bandwidth concern
the big picture is transactions get sent around the network of non mining nodes so that nodes have a store of transactions ready for when a block is created the node has the transactions in mempool to quickly validate the block and not need to regrab transactions after the blocks arrives. to allow quick propagation of blocks.

the whole point of relaying transactions is to give nodes transactions
dropping them defeats the whole point of sending them in the first place.
thus making relaying transactions pointless if now devs think its ok to not keep transactions

if gmaxwell thinks dropping transactions is perfectly fine then why even bother sending transactions to non mining nodes.
save more bandwidth by only sending transactions to nodes that flag that they are pools, by having a mining flag for instance
(yes you will argue that will cause more propagation issues.. i will reply yes welcome to the issue as i was being reverse psychological to prove a point)

also when
nodeX gets a tx from a peerA and drops it. that does not mean the next peerB suddenly doesnt need to send the same tx to
nodeX. peer B will still see nodeX doesnt have the tx and WILL resend it... and nodeX will drop it again
peer C will still see nodeX doesnt have the tx and will send it... nodeX will drop it

its not fixing the big picture of getting nodes to keep transactions so that compact blocks can propagate quickly. as the whole point of relaying transactions to non mining nodes is to give them transactions they dont have.

and the minisketch doesnt solve the problem of having to get the same data from peer b, c.

yet by removing the drop for silly reasons. means when node X gets tx from A.. it wont need to get it from B, C .. and wont need to get it after a block is solved... because.. big picture. it would already have it

oh, and if peer B,C doesnt have the tx to give. peer B,C wont get it from nodeX because node X didnt keep it so peer B and C will then be going through the same process of using bandwidth to try getting it from other peers

if everyone just kept to a same rule of only drop invalid transactions. everyone would all keep the same valid transactions without having to re send transactions or interrogate peers or re grab after compact block arrives.

and yes i can pre-empt the next empty argument
some fool will argue that peer A sent it at initial relay so now its peer Bs problem.. guess what
when a block is solved. guess who nodeX is going to ask again... yep. nodeA
and guess what nodeA will do. nodeA will resend it

some fool will argue that my concern only amounts to maybe 1 tx now and then..
nope if a node is saying drop transactions under 1000sat fee. there will be more than 1 tx now and again involved

devs always know of flaws, but instead of SOLVING the big picture they just OFFER flimsy, reduce the chances of flaw but not remove it

think about it
devs say this minisketch under their default setting tests shows a reduction of bandwidth to then allow a node that usually connects to 8 nodes could connect to 16-24 nodes (2-3x reduction) but thats not 7x reduction to allow 56 nodes.

and because settings are configurable around drops. if they ran tests using variable settings instead of just spinning up 8 nodes using defaults. the reduction would be LESS than 2-3x

and ontop of that. nodes still end up grabbing data after a compact block. meaning although they grabbed a tx severals times from peers at initial relay. they still grab again at block receipt. causing block propagation delays

where as removing configurable settings for silly reasons would actually give a better bandwidth reduction and make compact blocks not need to trigger as much bandwidth for the same dang tx's

and an outside the box thought. if they actually removed the drop for silly reasons and put in a fee priority formulae that al nodes utilitise so that there still remains control over spammy dust. a fee formulae can actually make spammers pay more for sending spammy dust without it affecting everyone fees at block confirm.

but nah.. devs just wanna OFFER flimsy stuff.. and not SOLVE the big picture

I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.
Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at
franky1
Legendary
*
Offline Offline

Activity: 2450
Merit: 1451



View Profile
December 29, 2018, 02:38:45 PM
Last edit: December 29, 2018, 03:43:51 PM by franky1
 #83

AFAIK the main problem of malleability was that exchanges could get fooled by a malleated tx such that their software couldn't recognise the malleated (broadcasted by the attacker) tx had indeed suceeded and the original one didn't, so they would end replaying it making a double (or multiple by rinse and repeat) spend themselves. <- REAL spends, don't confuse with the "double spend" attack.

It seems to me THAT problem has a solution now as exchanges can use the "specific format" that makes malleability impossible.

Ok, main problem solved.

Now go to the next one... You are saying that if I am the receiver I don't control the sending tx, which is true. So the "attacker" can choose to send me a tx which is susceptible of malleability, ok. And now what? The "attacker" is going to send me multiple malleated tx's? What can I say... thanks?

I think I am not getting it... can you use another example but instead of guns use a real life example on how that would be detrimental to me as a receiver of a Bitcoin tx?

yea your not getting it...you think the main problem is solved..
EG
if i sent you a tx of
1franky(0.1) -> bc1qexchange(0.1)
that tx is not a segwit tx. i can still malleate my signature to change the txid even when you want the funds to arrive at a segwit bc1q address

so an exchange will still get transactions that can be malleated..

all an exchange has control over is. if an exchange CHOOSES to only use segwit. then the exchange itself cannot malleate..
it doesnt mean an exchange cant be victim to malleation

segwits false promise was to solve malleability for the bitcoin network.. it hasnt
segwits real purpose was to add a gateway tx format to a different network which the different network would offer different things

I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.
Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at
franky1
Legendary
*
Offline Offline

Activity: 2450
Merit: 1451



View Profile
December 29, 2018, 03:32:15 PM
 #84

anyway this topic has got so derailed.

anyway. if nodes want to be fullnodes and validate all transactions, keep all transactions and when a block arrives confirm block and keep block.
then having configurable features that then dont validate, dont keep and dont send full data is not a full node. especially if the configurations are for silly things that can be solved in a multitude of other ways

i know blah blah blah rebuttal of define full node define less than full node define litenode define spv

but in short if you going to
prune the block archive,
reduce mempool holding
cause issues with block propagation latency
drop transactions
not relay certain tx
drop and regrab

your not helping the network

if core want to be the "full node" provider. they should concentrate on being a full node and concentrate on fixing network wide flaws. let other teams play around with providing less than full nodes user configurable flimsy stuff..

or more appropriate. core fans shouldnt do REKT campaigns on other teams that also wanna be full node providers

I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.
Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at
bitserve
Hero Member
*****
Online Online

Activity: 910
Merit: 765


HODL.


View Profile
December 29, 2018, 05:49:55 PM
 #85

AFAIK the main problem of malleability was that exchanges could get fooled by a malleated tx such that their software couldn't recognise the malleated (broadcasted by the attacker) tx had indeed suceeded and the original one didn't, so they would end replaying it making a double (or multiple by rinse and repeat) spend themselves. <- REAL spends, don't confuse with the "double spend" attack.

It seems to me THAT problem has a solution now as exchanges can use the "specific format" that makes malleability impossible.

Ok, main problem solved.

Now go to the next one... You are saying that if I am the receiver I don't control the sending tx, which is true. So the "attacker" can choose to send me a tx which is susceptible of malleability, ok. And now what? The "attacker" is going to send me multiple malleated tx's? What can I say... thanks?

I think I am not getting it... can you use another example but instead of guns use a real life example on how that would be detrimental to me as a receiver of a Bitcoin tx?

yea your not getting it...you think the main problem is solved..
EG
if i sent you a tx of
1franky(0.1) -> bc1qexchange(0.1)
that tx is not a segwit tx. i can still malleate my signature to change the txid even when you want the funds to arrive at a segwit bc1q address

so an exchange will still get transactions that can be malleated..

all an exchange has control over is. if an exchange CHOOSES to only use segwit. then the exchange itself cannot malleate..
it doesnt mean an exchange cant be victim to malleation

segwits false promise was to solve malleability for the bitcoin network.. it hasnt
segwits real purpose was to add a gateway tx format to a different network which the different network would offer different things

Of course you can malleate your own legacy transactions, so what?

I only care if I have received the BTC in the intended deposit address and how many confirmations it has. You can malleate and rebroadcast your tx as many times as you want (which is pointless because as soon as the first one wins the race all the rest will get rejected), I don't care what the txid is as I am not checking for it.

You have failed to provide an example about how that known behaviour would become a PROBLEM/attack vector in real life.

Yes, Segwit main purpose was always to facilitate the integration of L2 and to allow more transactions without having to increase the block size just yet. The fact that it does offer a viable solution to the transaction malleability problem was more of a side effect / secondary goal.

P.S.: Also, transaction malleability was a problem due to poor coding and lack of redundancy/cross checks on whatever exchange got affected (if any). A simple reconciliation of the balance of input addresses BEFORE doing any retry would have easily detected and stopped the exploit.

19VBmRQVqrtNTGiwngZutwREagcKxJgVZM
franky1
Legendary
*
Offline Offline

Activity: 2450
Merit: 1451



View Profile
December 29, 2018, 06:01:23 PM
Last edit: December 29, 2018, 06:25:22 PM by franky1
 #86

Of course you can malleate your own legacy transactions, so what?

You have failed to provide an example about how that known behaviour would become a PROBLEM/attack vector in real life.

you failed to understand the malleability problem
though this is offtopic... and i know im being poked by an obvious fan groupy based on certain terms you use, ill bite
you said:
It seems to me THAT problem has a solution now as exchanges can use the "specific format" that makes malleability impossible.
i replied
if i sent you 1franky(0.1) -> bc1qexchange(0.1)
you said
Quote
Of course you can malleate your own legacy transactions, so what?
so even when you as an exchange use a specific format... i can still malleate a tx to you
maybe go do some research.. you know... google

hint, its not about confirmed transactions. never was about confirmed transaction.. never has been about confirmed transactions.
if you want to argue and say there never was a problem then take that up with the devs who obviously thought there was a problem for them to do what they did and promote what they did.

also lightning network is not a layer two feature of bitcoin.
its a completely separate network that allow multiple different coins to get locked up and then people get to play around on this other network.

its not scaling bitcoin network. its diverting people away from using the bitcoin network.
might be worth you doing research beyond the utopian dream promotional material

...
lets get some things straight here.
for people to be on this forum means they have already heard about bitcoin and crypto.. after all they didnt magicly just gt dropped into the forum.

they dont need the wishy washy only positive advertising of utopian dreams and empty promises.. they want to know what is really going on.. both good and bad.

i understand there is a group of people that only want to overpomise and fluffy cloud unicorn stuff with positive chatter.. but thats just not really doing much because to read that stuff here in the forum is advertising to people that already been advertised to.

people want to know whats beyond the fluffy clouds

I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.
Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at
gmaxwell
Staff
Legendary
*
Offline Offline

Activity: 2772
Merit: 2333



View Profile
December 29, 2018, 06:29:14 PM
Last edit: December 29, 2018, 06:43:27 PM by gmaxwell
Merited by bitserve (1)
 #87

- Also it seems to me that in any case minisketch has nothing to do about that because the drop of the tx's due to not meeting the min relay criteria is a previous step in the protocol. Minisketch just adds an optional and more efficient (bandwidth wise) way of dealing with a preexistent situation.

You've got it.

The "re-relay" problem that he imagines isn't actually a thing, but even if it were, minisketch would just be an unrelated improvement:  Nodes communicate their minfeerate to peers and don't get offered stuff they'll just drop due to fees. Existing things they do drop (due to being double spends, arriving while they're in the process of changing their fee filter, etc) they remember the txids so they won't fetch them again if a peer offers them, which itself doesn't happen much because txn are only offered when the peer initially accepts them.

Quote
allow more transactions without having to increase the block size just yet.

https://blockchair.com/bitcoin/block/544791
Size (bytes)    1,700,065

Last I checked 1700065 was greater than 1000000. Smiley Segwit increased the blocksize, but didn't increase the size that lite clients have to deal with or break compatibility.

Quote
facilitate the integration of L2
Not really, I mean that might have been why many people on the forum found it exciting,  but separating out witnesses was proposed back in 2012 when no one was really thinking much about L2.   Unintended malleability is just a source of 1001 awful corner cases that are really hard for wallets to handle except by refusing to spend your own unconfirmed outputs, or other similarly terrible and burdensome workarounds. We previously tried fixing these problems via BIP62 but it was just a finger in a failing dam, because the original design was flawed we kept finding more and more avenues and were forced to abandon that approach.  Lightning was proposed before segwit was a thing and at least theoretically lightning can be done without it-- but in practice without the ability to control malleability it is just too awful and dangerous to write any automatic transaction processing software, so after segwit was proposed which completely solved that issue lightning developers decided to wait on its availability.

Quote
Also, transaction malleability was a problem due to poor coding and lack of redundancy/cross checks on whatever exchange got affected (if any). A simple reconciliation of the balance of input addresses BEFORE doing any retry would have easily detected and stopped the exploit.
Not quite-- MTGox's claims were indeed just trying to cover up his insolvency cover-up, but even without that easily fixed accountability screwup malleability is a problem because of spending change output.  There were several big attacks that really messed up and took down basically every big fund sender (e.g. bitstamp)-- we kept them under control by getting miners to blacklist various attack patterns, but that kind of workaround can be evaded by sufficiently motivated attackers.  It actually was important to fix the general case for reasons unrelated to mtgox.  Mtgox just seized on and exaggerated an existing problem that had given then a little trouble (and unlikely ~everyone else actually caused them some funds loss, rather than just a jammed wallet) ... but it still was actually an existing problem.  It was strategic for mtgox to lie in this way, had they imagined some totally new fake problem to blame their insolvency on they would have instantly been called out.

I really don't understand why FUDsters have had any success with the "malleability isn't fixed".  The fact that it's possible to intentionally make a malleable transaction even exists as a useful and intentional feature: e.g. the ability to create anyonecanpay transactions where other people provide part of the funds after you sign. The malleability issue was always that it wasn't possible to spend an unconfirmed output (e.g. as your change, wallets have always refused to spend unconfirmed outputs by other people due to the risk of double spending) without those dependant spends (and their ancestors) being maliciously invalidated by someone else.   -- it's not like intentional malleability is avoidable, after all you could also always double spend yourself.

I guess some people are just pathologically uncomfortable with anyone else having any choice at all in their life.  The fact that you could choose to intentionally make a transaction that they allow other people to modify, and then have to deal with the consequences yourself just seems to drive some people wild.  Similarly, the fact there is some buried command-line configuration option that virtually no one sets to increase the minimum feerate your node will accept-- with essentially no consequence for anyone but yourself-- causes the same people to melt down ... the idea that other people can make their own free choices seems to leave some unable to sleep and stuck obsessively posting about it. The fact that their choice harms no one and is fundamentally impossible to prevent is apparently just not relevant to these people.

Unfortunately, other people see the floods of posts and think that there must be some issue.  But no: sadly, some people on the internet are just broken.

It's really frustrating that they'll say anything to sustain their obsessions ... like above "they introduce RBF to actually help malleators malleate" uh no, third part malleability always either lower feerates or keeps it the same, so if RBF mattered at all it would actually make malleability less sucessful by allowing the original to replace (in practice it doesn't because the mallated txn is only larger by one byte). Not only is the claim untrue, if anything it's the opposite of the truth.  But the speaker will never suffer any negative consequence that he cares about for spreading this lie, and it might convince some ignorant party... so he'll do it every time.
franky1
Legendary
*
Offline Offline

Activity: 2450
Merit: 1451



View Profile
December 29, 2018, 06:47:11 PM
Last edit: December 29, 2018, 07:46:12 PM by franky1
 #88

Quote
allow more transactions without having to increase the block size just yet.

https://blockchair.com/bitcoin/block/544791
Size (bytes)    1,700,065

Last I checked 1700065 was greater than 1000000. Smiley

last time i checked 3169 transactions was not more than the 4200tx of 7tx/s
last time i checked 3169 transactions didnt need 1.7mb
last time i checked 1.7mb for ~3200tx is not hard drive efficient transacting (over 500bytes average per transaction (facepalm))

last time i checked the whole 7tx/s capability. =604ktx a day
we have not had a single day of more that 600k... allthough the fluffy unicorns will promote 4x weight is now achievable........
oh and dont try with the 'theres no demand' pfft. there have been many days of mempools being above average and people waiting more then one block.. but last time i checked even in them situations we didnt get a single day above a 600k tx day

come on wheres the utupian fluffly cloud of upto 24,000tx a day
.. go on admit it. the witness scale factor limits actual full utility of 4mb weight, due to how transactions are fully(legacy) and partially(segwit) still limited to a 1mb limit hidden from being called a 1mb base block due to the wishy washy code of witness scale factor

come on wheres the utupian fluffly cloud of upto 24,000tx a day
.. go on admit it. even if everyone was to only use segwit transactions the expectation would be only a 2.5x utility average

I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.
Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at
franky1
Legendary
*
Offline Offline

Activity: 2450
Merit: 1451



View Profile
December 29, 2018, 06:58:26 PM
Last edit: December 29, 2018, 07:23:36 PM by franky1
 #89

wallets have always refused to spend unconfirmed outputs

last time i checked you could actually broadcast an ancester and broadcast a child and a blockcreator would include the ancester and child in the same block
thus the child that has funds originating from the ancester doesnt need to wait for a confirm(separate block)

all the block creator would do is make sure the child was listed after the ancestor in the same block. and it would be treated as valid

I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.
Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at
franky1
Legendary
*
Offline Offline

Activity: 2450
Merit: 1451



View Profile
December 29, 2018, 07:22:46 PM
Last edit: December 29, 2018, 07:52:31 PM by franky1
 #90

I guess some people are just pathologically uncomfortable with anyone else having any choice at all in their life.  The fact that you could choose to intentionally make a transaction that they allow other people to modify, and then have to deal with the consequences yourself just seems to drive some people wild.  
put the shoe on the other foot.. think outside your echo chamber box of fluffy clouds and utopia

i guess devs who pretend to care about network and user security are comfortable with not caring about the network and security. letting users who are not technical unintentionally make transactions that others can modify,. and then just saying its upto the users to deal with the consequences themselves....

Similarly, the fact there is some buried command-line configuration option that virtually no one sets to increase the minimum feerate your node will accept-- with essentially no consequence for anyone but yourself-- causes the same people to melt down
no consequence to others?
.. block latency/propagation delays for their peers..
...only getting transactions relayed if you pay more just to get your peers to relay/retain your transaction
...peers need to send transactions more then once due to the other person dropping..


*separating out witnesses was proposed back in 2012 when no one was really thinking much about L2.  
#Lightning was proposed before segwit was a thing

*chicken or #egg.. choose one then stick with it.. which came first?

It's really frustrating that they'll say anything to sustain their obsessions ... like above "they introduce RBF to actually help malleators malleate" uh no, third part malleability always either lower feerates or keeps it the same, so if RBF mattered at all it would actually make malleability less sucessful by allowing the original to replace (in practice it doesn't because the mallated txn is only larger by one byte). Not only is the claim untrue, if anything it's the opposite of the truth.  But the speaker will never suffer any negative consequence that he cares about for spreading this lie, and it might convince some ignorant party... so he'll do it every time.
im laughing..
people who RBF DONT lower the fee for the second(replacement) tx...
they increase the fee as a bribe to blockcreators to include the second tx with the greater fee and drop the first one with the lower fee.
i do laugh that you think malleators would even try to do RBF using a lower fee replacement....

seriously. im laughing now.
you really do try to downplay things and hide issues under the rug.

the mindset is comedy
1. let users deal with consequences
2. theres a big picture flaw but this feature wont solve it, its "exclusive" to only reduce potentially a small amount of change
3. offering choice is a users problem
4. devs cant solve the issue its impossible

It's really frustrating
whats really infuriating to you, is that some people just wont be sheep and kiss asses then just bite their lip
i know you want to be a founders, a team leader, a chief, a boss, a top guy because you dont like having people to answer to and dont like having people tell you when your not doing your job properly..
.. but welcome to the real world

and no your not on your last chicken nugget with no money left so are wanting to hear violins.
everyone knows your well paid. so dont play the victim card

I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.
Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at
gmaxwell
Staff
Legendary
*
Offline Offline

Activity: 2772
Merit: 2333



View Profile
December 29, 2018, 08:10:49 PM
Last edit: December 30, 2018, 02:08:08 AM by gmaxwell
Merited by franky1 (1), Toxic2040 (1)
 #91

last time i checked 3169 transactions was not more than the 4200tx of 7tx/s
last time i checked 3169 transactions didnt need 1.7mb
Bitcoin's capacity has never been "tx/s", the "7tx/s" number comes from assuming every transaction would be a 2-in-1-out transaction.  The block I gave an example of would have only held slightly more than half the number of transactions without segwit. You can also see the effect of the increased capacity because fees have dropped to almost nothing again.

The block I linked to spent 9,039 inputs, which would have been impossible prior to segwit: each input takes 147 bytes, so without segwit a block could only have spent 6,802 even if it made no outputs at all. The block I linked to also made 3,553 outputs.

If all you care about is number of transactions, this block has 12,239... or 20.3 tx/s ... though they are all very small inefficient one-in-one-out transactions without real signatures. Size wise they are functionally segwit transactions because they have empty scriptsigs (technically one byte). (And yes, because segwit was a softfork, segwit-like transactions could be included in the chain from day one, they didn't have to wait for segwit -- they only had to wait for segwit to be secure).

Quote
last time i checked 1.7mb for ~3200tx is not hard drive efficient transacting (over 500bytes average per transaction (facepalm))
Again your posts are the opposite of the truth.  Services now use sendmany (and indiviguals sometimes coinjoin) combining many transactions into one. This makes the much more efficient. One transaction does the work of three but is only 1.5x the size...


wallets have always refused to spend unconfirmed outputs
last time i checked you could actually broadcast an ancester and broadcast a child and a blockcreator would include the ancester and child in the same block
thus the child that has funds originating from the ancester doesnt need to wait for a confirm(separate block)
all the block creator would do is make sure the child was listed after the ancestor in the same block. and it would be treated as valid

You have maliciously misquoted my message.

Quote
everyone knows your well paid
In fact, I haven't made any income for since 2017-12-31-- beyond a couple tens of dollars worth a month for helping with forum moderation. I live off selling investments. Not that it's any of your business. But for the record, just in case there are other similar pieces of shit to you that think it's okay to treat your fellow man like dirt relentlessly lying and throwing shit at him simply because you think he earns more than you. I hoped that the dishonest attacks would diminish if I had not further relationship or contact with Blockstream, and for the most part that has been true: It turns out that most of the slimeballs can't find anything negative to say except for baseless slander about where I work. Now, without that to hang their arguments on, they're mostly left either lying about where I work, or saying nothing.

I feel sad that you are such a loathsome and dishonest person, and sad for the world for all the damage you do to it.
franky1
Legendary
*
Offline Offline

Activity: 2450
Merit: 1451



View Profile
December 29, 2018, 09:12:19 PM
Last edit: December 29, 2018, 11:02:36 PM by franky1
 #92

now we really are going off subject. but he pokes, so ill bite. i know he had me on ignore for along time so i guess he has alot on his chest he wants to cough up.. just a pitty that the issues raised are concerning bitcoin code. which he is involved in thus he cant really blame me for bitcoin flaws that he and his his team dont want to fix, or he and his team have caused to sway people away from bitcoin...

but anyway

The block I linked to spent 9,039 inputs, which would have been impossible prior to segwit: each input takes 147 bytes, so without segwit a block could only have spent 6,802 even if it made no outputs at all. The block I linked to also made 3,553 outputs.
but do you want to know a real funny thing. something you tripped up with when you said impossible to let in ~9000 inputs
into a block pre segwit... here it is.. your words
If all you care about is number of transactions, this block has 12,239... or 20.3 tx/s ... though they are all very small inefficient transactions.
block 367853
Mined on    2015-08-01
Transaction count    12,239
Input count    13,176
Output count    12,917

year 2015=legacy block = pre segwit(2017)

but i do find it funny you shot yourself in your own foot with your own ammo.. by saying legacy couldnt handle it,, but then display it could... comedy gold..

EDIT: actually because of the comedy above of shooting yourself in the foot. ill actually give you a merit

anyway
i knew about that block and tx count.. secondly i dont deal with utopian single use case fluffy clouds. hense why i only mentioned the 7tx/s more rational numbers of rational usage and i broadened it to a 600k tx a day
because in reality people dont rely on single case examples. they prefer average expectations of real possible utility

and yes individual transactions is an indicator of individual users... batched transactions is an indicator of foolish people trusting funds to exchanges/middlemen and services.. so yea. i prefer to measure bitcoin by its transaction count
..

so since 2015.. when you first made the roadmap.. knowing what bitcoin was capable of (your own gunshot above) what have devs actually done to get passed a rational 600k a day tx expectation..
and please please dont refer to features that are purposed to divert people off the network

Quote
last time i checked 1.7mb for ~3200tx is not hard drive efficient transacting (over 500bytes average per transaction (facepalm))
Again your posts are the opposite of the truth.  Services now use sendmany (and indiviguals sometimes coinjoin) combining many transactions into one. This makes the much more efficient.
batching transactions was a thing even back in 2015 and before that........ so.. nothings different.

Quote
everyone knows your well paid
In fact, I haven't made any income for over a year now-- beyond a couple tens of dollars worth a month for helping with forum moderation. I live off selling investments. Not that it's any of your business.  But for the record, just in case there are other similar pieces of shit to you that think it's okay to treat your fellow man like dirt relentlessly lying and throwing shit at him simply because you think he earns more than you.  I'm sure that you suffer because your paid shilling doesn't pay well, but that isn't anyone elses problem... And indeed, I am far from broke, but that doesn't make continued efforts worth any time in particular.
The fact of the matter is that I'm not paid to work on Bitcoin, I've done it because I love it and care about its contribution to the world... but it's probably just not worth it when dishonest shills like you can just bury everything in shit and discord and almost no one will do anything to stop you.  Maybe the world just isn't ready for bitcoin.

1. i learned that ages ago that your ready to retire. which is why people should care more about bitcoins network security rather than devs. devs retire, devs move onto different projects, devs get bored.
too many people think your immortal and will be around forever. fact is even you have to admit you wont be,
you already semi retired when you left(well you announced you left) blockstream
.. devs move on retire, get old, have medical issues. get bored.. many reasons to not depend on a dev and only depend on network security.
.. just like satoshi, just like hal, just like many other devs... your not the first, and you wont be the last.
holding you up as an immortal god that will last forever.. caring more about you then network security of a global system is not in peoples interest.

2. your interests are not bitcoins network interests. or the communities interests. you made that clear by saying many things over many years about how things should not be fixed and left for users to deal with the consequences, users should just fork off, and many other things
 you guys even have the cowardice to still 9+ years on to call it an experiment. a betatest, a 0.x version. and to pretend at any community event to be just janitors when it comes to community desires, but then suddenly maintainers, chief technical officers of "the reference" "the core" when it comes to feature you want

3. i dont get paid to shill. i dont get paid to kiss ass. if anyone tried to pay me to change my opinion i would laugh at their attempts. even if someone tried to twist my words and then attempt to make a 25btc bet with me to prove a word twist, id just laugh at them. because they are the ones that are failing.

my income is from investments i made from 2012 and i am happy. i get to travel the world. some may think that because im posting night and day means i have some sleep problem due to bitcoin issues. when infact its simply me adjusting to different timezones

4. as for your actions i learned early on. you set yourself a goal of a one way street one direction future for bitcoin.. well not a street. lets call it a roadmap.
this roadmap is leading to getting people to mve their funds into locked vaults (issue: many more UTXO locked for longer periods than expected, while reducing the number of tx counts onchain).. just to push people into using a different network which is using th same business model as banks did in the 18th century in regards to gold

the thunderdome: 1 gold may enter 100 silver may leave... oops sorry i admit that was a misquote.. but close enough to hint at the lightning business plan compared to banking

5. and before you continue coding features not designed for network security, but for privacy of certain users..that WILL bloat transactions further.. yea i know u want to keep witness scale factor in play to hide how much bloat that feature will add to hard drives

ill say this
removing users ability to transparently audit bitcoins value.(confidential transactions) might look like a user convenience for the privacy conscious. but from a network security/audit prospective.. it just turns into a ledger of data it cant audit.
i know you'll say thats the point of your TX bloating 'payment codes'.. oops i mean commitments.. but it just makes the archived data just a ledger of useless data to the decentralised world.
things like that lead to people thinking, whats the point in being a full node

so instead of telling the community to go fork off oops lets use your words bilateral fork
so instead of telling the community alternative networks offer more than the bitcoin network does

how about actually stop pretending you care about bitcoin. and actually care about it. or man up and put your concentration to the real projects you care more about, like the alternative network known as lightning.. which i know you want because your investors ($101m) will want to get some returns on their investment. and yes. although you announced you left as a CTO, we all know deep down your still tied to it

I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.
Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at
bitserve
Hero Member
*****
Online Online

Activity: 910
Merit: 765


HODL.


View Profile
December 30, 2018, 06:46:35 AM
Last edit: December 30, 2018, 11:13:36 AM by bitserve
 #93

@franky1 I don't understand why you insist in the constant bashing and ridiculous ad hominem attacks against gmaxwell.

No, I am not a "groupie fan" as you say. While I do appreciate the work of Core there are some things I don't completely agree. Ie: At the time, I would have preferred that consensus went for Segwit2x, it didn't happen though... And consensus is much more important than some political/technical details.

I am an L2/LN fan though. You seem to be not, it's ok.

You seem to have studied or at least devoted enough time to learning many of the technical details of Bitcoin and to be somewhat knowledgeable in the subject. In contrast, some of your conclusions or narrative seem to be wrong. For example it has been clearly demonstrated that your strong narrative against Minisketch and some of your support points were (either intentionally or not) completely misleading and/or plainly wrong.

If you focused your effort in more objective facts instead of trying to desperately find arguments to support your preconceived and misleading conclusions maybe you would be way more constructive. Just saying.


@gmaxwell Thank you very much for all the clarifications and your contributions to Bitcoin!

19VBmRQVqrtNTGiwngZutwREagcKxJgVZM
Toxic2040
Hero Member
*****
Offline Offline

Activity: 658
Merit: 1033



View Profile
December 30, 2018, 08:41:30 AM
 #94

@gmaxwell

Never doubt that your hard work with bitcoin is unappreciated...it is very much so. That your taking the time to form coherent rebuttal's against a obvious troll is commendable as well.

Thank you.
tc
franky1
Legendary
*
Offline Offline

Activity: 2450
Merit: 1451



View Profile
December 30, 2018, 12:46:54 PM
Last edit: December 30, 2018, 01:58:08 PM by franky1
 #95

In contrast, some of your conclusions or narrative seem to be wrong. For example it has been clearly demonstrated that your strong narrative against Minisketch and some of your support points were (either intentionally or not) completely misleading and/or plainly wrong.

the thing is i see the big picture.
EG
issue: with bandwidth in relation to sending transactions so that users have them before a block is transmitted
reason: so that a block can be compact and users then dont need to grab transactions after compact block

instead of thinking of bigbox solutions that solve the whole issue. devs waste months and years on "exclusive" things that only handle a small offering, and only a offering for people who choose to use it. while not solving the broader big picture problem for the whole network

EG minisketch does not ensure nodes have every VALID transaction so that when a block arrives it can quickly validate a block without delay.
all because devs let users have configurable settings to play around and cause bottlenecks by being biased against certain transactions. thus ending up needing to retransmit transactions, causing delays in propagating blocks... all for the sake of 'user choice' which does affect other people (imagine the '8 degrees of separation theory' playing a game of chinese whispers)

if core want to be the defacto full node and network security offering the most efficient node that has least chance of block propagation latency.. then be a full node. take out all the funk that reduces a core node from being a full node. take out the user configurable stuff that can cause resends and latency. then you will find that resends and latency dont happen by default

if some users cant handle being a full node then they have the choice of electrum and other spv/litenodes
....
my other issue is how core devs dont want other teams to offer a full node option.. (unless the other team are actually colleagues/buddies)
take luke Jr's mandated follow core rules or get "f**k off" the network (UASF(it was actually a MCHF:mandated controversial hardfork)) or what greg would call a bilateral fork
take greg also loving the idea of hard forks if core dont get their way and others are trying to offer something different ON THE NETWORK

What you are describing is what I and others call a bilaterial hardfork-- where both sides reject the other.

I tried to convince the authors of BIP101 to make their proposal bilateral by requiring the sign bit be set in the version in their blocks (existing nodes require it to be unset). Sadly, the proposals authors were aggressively against this.

funny part about the whole 2016-17 saga is that if core actually went with a segwitx2. it would have activated segwit much sooner.. and without the august hard fork
funny part is all the drama of core pretending to delay things to avoid a hardfork, ended up with one happening anyway due to their one direction, push it till its forced, no consideration for the community, no compromise to find a middleground mindset

if core actually listened and actually compromised some of cores demands to meet communities wishes.. core would have got segwit sooner and the community would have got more legacy utility.

and last funny part. with the now 95% core dominance. there is no actual reason to keep the witness scale factor in play, as there is not a controversial enough diversity of nodes to cause issues.. i find it funny because the august 1st event could have ben utiiised better to get rid of the (hidden by witness scale factor) 1mb allowance area completely. thus letting both legacy and segwit actually both function and both have full access to upto 4mb..

but no.. they done a half assed job because they have a roadmap that goes against opening utility on the network, because they need people to move over to LN so that greg and lukes investors can make some returns

I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.
Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at
franky1
Legendary
*
Offline Offline

Activity: 2450
Merit: 1451



View Profile
December 30, 2018, 01:23:10 PM
Last edit: December 30, 2018, 05:17:56 PM by franky1
 #96

I am an L2/LN fan though. You seem to be not, it's ok.

i am not dead against lightning. i understand its NICHE. but i am a realist who is happy to be loud enough to inform people of its negatives and limitations. i dont like the false advertising "this is a fluffy unicorn solution that will solve everything" over promise that keeps happening
here are the devs themselves admitting LN has issues. limitations, complications
https://youtu.be/8lMLo-7yF5k?t=570

as for lightning. calling it a bitcoin layer or a bitcoin feature is just propaganda sponsorship buzzwords to make investors think they are buying into bitcoin because a separate network is throwing the word bitcoin about ALOT(too often).
funny thing is like how blockstream throw in the word bitcoin to get investment.. but then try to downplay and say that the money they get from blockstream investors has nothing to do with bitcoin development
or how litecoin is bitcoins silver
or how circle is bitcoin service (though its actually a FIAT business)

LN is a separate network. if no bitcoiners used LN, LN would still function. as its a separate network that litecoin and vertcoin and other coins can already do and will continue to use no matter if bitcoin is popular or not.

research it. hint: chainhash
here ill even show you a few lines of code that LN is not a bitcoin feature but a separate network for different coins
https://github.com/lightningnetwork/lnd/blob/master/chainregistry.go#L580
Code:
litecoinMainnetGenesis = chainhash.Hash([chainhash.HashSize]byte{
0xe2, 0xbf, 0x04, 0x7e, 0x7e, 0x5a, 0x19, 0x1a,
0xa4, 0xef, 0x34, 0xd3, 0x14, 0x97, 0x9d, 0xc9,
0x98, 0x6e, 0x0f, 0x19, 0x25, 0x1e, 0xda, 0xba,
0x59, 0x40, 0xfd, 0x1f, 0xe3, 0x65, 0xa7, 0x12,
})

// chainMap is a simple index that maps a chain's genesis hash to the
// chainCode enum for that chain.
chainMap = map[chainhash.Hash]chainCode{

bitcoinTestnetGenesis:  bitcoinChain,
                litecoinTestnetGenesis: litecoinChain,

bitcoinMainnetGenesis:  bitcoinChain,
litecoinMainnetGenesis: litecoinChain,
}

also knowing it locks up coins on network is going to cause UTXO sets get locked up. which lets say just VISAUSA user numbers(not global) used LN. thats 189million UTXO locked for long time periods and not transacting onchain. which will strain fullnodes UTXO issues while fullnode users are then seeing 'empty blocks' leading to less people wanting to be full nodes

having empty blocks is not making bitcoin better, its making bitcoin worse because all it does is when pools want/need fee's to pay for mining. the fee's for the FEWER users remaining on bitcoins network will have to pay more to get a confirm.

again diverting people off network does not help the network.
oh and please dont even bother with the old myth of "gigabytes by midnight" is the only other solution to a non-LN situation
oh and please dont even bother with the old myth of to pay miners limitations are needed on the network to force users to pay more.
oh and please dont bother with the old myth that LN solves the problem for everyone. LN is for a niche of users that spam alot and often. not everyone spends every day so having to lock funds up, spread funds over channels and be online all the time just to get paid is not a benefit to them.

there are many ways. to ofset the spammers from the ones that wont benefit
here is one which doesnt cause every user on the bitcoin network needing an increasing average fee.
(EG current situation. if one person spams txs into a block everyone has to pay a higher fee to bribe a pool)

while also (unbiasedly) persuading the spam every block regular spenders who 'could' benefit from LN to then use it
as using the bitcoin network is costing just the spammers more

so lets think about a priority fee thats not about rich vs poor(like the old one). not about a network wide everyone should pay an estimated average increased fee(like currently) but about respend spam and bloaters pay more, and everyone else pays for what they use dependant on personal circumstance.

lets imagine we actually use the tx age combined with CLTV to signal the network that a user is willing to add some maturity time if their tx age is under a day, to signal they want it confirmed but allowing themselves to be locked out of spending for an average of 24 hours because they are happy to wait to get cheaper fees.. or rduce the lock if they want priority by paying more for less delay.

and where the bloat of the tx vs the blocksize has some impact too... rather than the old formulae with was more about the value of the tx


as you can see its not about tx value. its about bloat and age.
this way
those not wanting to spend more than once a day and dont bloat the blocks get preferential treatment onchain.
if you are willing to wait a day but your taking up 1% of the blockspace. you pay more
if you want to be a spammer spending every block. you pay the price
and if you want to be a total ass-hat and be both bloated and respending often you pay the ultimate price

and lastly about lightning..
if you research into eltoo and read about the purpose of factories. to vault coins up(step 1) and then separately a step away from the blockchain create unconfirmed/unaudited payments.. which are then sent to users for users to use those as their channel open initial states(not blockchained UTXO)

this makes factories like the fortknox of gold then offering promissory notes.
the purpose then is to PREVENT USERS from just exiting back to bitcoins network. but instead hand back the unconfirmed updated initial state payment. to a factory. and the factory just give them new crisp unfolded payments to open channels.

meaning people are less able to individually just exit back to bitcoins network.. much like how banks done it with the gold/bank note business plan in the 18th century.. and we know how that played out

thunderdome: 2 may enter but only 1 may leave
LN factory: bitcoin and litecoin may enter but only litecoin may leave
banks: gold and silver may enter, but only silver may leave

yes factories are designed to reduce/prevent users broadcasting back to the bitcoin network.
you can dress it up in as many pink dresses and fluffy unicorns of how its a benefit. but atleast be open minded to the consequences.. after all banks done the fluffy unicorn promotions too about how returning back to gold was 'bad' and stayin with vaulted up gold while playing with unaudited payment methods was good

again i understand LN's NICHE utility for the few that may need it. but over selling LN as the utopia solution for all. and selling it as a feature of bitcoin.. is going too far. especially as those overselling LN are the ones saying bitcoin cant cope.. which leads to actually people prefering to leave LN using other coins.. thus not helping bitcoin

I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.
Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at
hv_
Hero Member
*****
Offline Offline

Activity: 1260
Merit: 543

Clean Code and Scale


View Profile WWW
December 30, 2018, 02:45:36 PM
 #97

^

Yep. And full nodes honest mine and are incentivized by coinbase rewards and fees in future.

All other peripheral 'nodes' must follow, can do some recon jobs or relay some few new txs.

LN and other peripheral non bitcoin tech only weaken bitcoin s original economy.

Carpe diem  -  understand the White Paper and mine honest.
Memo: 1AHUYNJKPfY7PjVK1hNQFo5LrdGixuiybw  -  https://metanet.icu/
The simple way is the genius way - in Moore's Law and Satoshi's WP we trust.
VB1001
Sr. Member
****
Offline Offline

Activity: 294
Merit: 711


"Four Wheel Drive"


View Profile
December 31, 2018, 07:25:26 AM
 #98

I have a question from some external Bitcointalk people, but they are interested in Bitcoin (this is good):
What solution is there in an exponential adoption of Bitcoin if the number of payments / transactions increases exponentially?

1PCm7LqVkhj4xRpKNyyEeekwhc1mzK52cT
bitserve
Hero Member
*****
Online Online

Activity: 910
Merit: 765


HODL.


View Profile
December 31, 2018, 08:28:37 AM
Last edit: December 31, 2018, 09:37:29 AM by bitserve
 #99

I have a question from some external Bitcointalk people, but they are interested in Bitcoin (this is good):
What solution is there in an exponential adoption of Bitcoin if the number of payments / transactions increases exponentially?

It would depend on the timeline.

If it was an exponential rise incredibly fast.... well, here is one of the reasons why I am a fan of L2/LN. But even in that case.... and many people won't like my answer:

Third party LN wallets.

Yes, what I mean is not everybody running their LN wallet.... I mean that if the rise of adoption were so huge and fast it would probably be "trusted" third parties offering wallets (similar of having some coins on a exchange) with many well funded open LN channels to act as a proxy for you. They would act in a similar way as a bank does.... but instead of controlling the majority of your funds it would only be a small pocket change amount you would think enough for your daily/weekly spendings. Of course your coins on that site would just be an OIU but they won't need to constantly open and close channels to other major parties bloating the blockchain. That way the amount of blockchain tx's won't be as much impacted. Your main stash would remain under the control of your keys, on the blockchain.

Of course I want to believe that in that situation there would be some consensus to also REASONABLY rise the block size limit as needed.

But, in any case, in the scenario you are describing, it would be needed to divert a majority of tx's (the popular "coofee" and "pocket change" tx's)  via L2 and maybe even through L2 "proxies" (third party L2 online wallets).



19VBmRQVqrtNTGiwngZutwREagcKxJgVZM
Wind_FURY
Hero Member
*****
Offline Offline

Activity: 1162
Merit: 785


Crypto-Games.net: Multiple coins, multiple games


View Profile
December 31, 2018, 08:33:22 AM
 #100

I am an L2/LN fan though. You seem to be not, it's ok.

i am not dead against lightning. i understand its NICHE. but i am a realist who is happy to be loud enough to inform people of its negatives and limitations. i dont like the false advertising "this is a fluffy unicorn solution that will solve everything" over promise that keeps happening
here are the devs themselves admitting LN has issues. limitations, complications
https://youtu.be/8lMLo-7yF5k?t=570


Like any other software development, it will have limitations. Bitcoin too can be viewed as a software experiment that could fail.

Quote

as for lightning. calling it a bitcoin layer or a bitcoin feature is just propaganda sponsorship buzzwords to make investors think they are buying into bitcoin because a separate network is throwing the word bitcoin about ALOT(too often).

funny thing is like how blockstream throw in the word bitcoin to get investment.. but then try to downplay and say that the money they get from blockstream investors has nothing to do with bitcoin development
or how litecoin is bitcoins silver
or how circle is bitcoin service (though its actually a FIAT business)

LN is a separate network. if no bitcoiners used LN, LN would still function. as its a separate network that litecoin and vertcoin and other coins can already do and will continue to use no matter if bitcoin is popular or not.


Lightning is NOT a separate network. All coins transfered within those payment channels ARE Bitcoins deposited in a 2-for-2 multisig address that have their transactions recorded locally, for the time being, until the channel closes, and the final state of the channel is broadcasted on-chain like an ordinary Bitcoin transaction.

Stop gaslighting.

Quote

research it. hint: chainhash
here ill even show you a few lines of code that LN is not a bitcoin feature but a separate network for different coins
https://github.com/lightningnetwork/lnd/blob/master/chainregistry.go#L580
Code:
litecoinMainnetGenesis = chainhash.Hash([chainhash.HashSize]byte{
0xe2, 0xbf, 0x04, 0x7e, 0x7e, 0x5a, 0x19, 0x1a,
0xa4, 0xef, 0x34, 0xd3, 0x14, 0x97, 0x9d, 0xc9,
0x98, 0x6e, 0x0f, 0x19, 0x25, 0x1e, 0xda, 0xba,
0x59, 0x40, 0xfd, 0x1f, 0xe3, 0x65, 0xa7, 0x12,
})

// chainMap is a simple index that maps a chain's genesis hash to the
// chainCode enum for that chain.
chainMap = map[chainhash.Hash]chainCode{

bitcoinTestnetGenesis:  bitcoinChain,
                litecoinTestnetGenesis: litecoinChain,

bitcoinMainnetGenesis:  bitcoinChain,
litecoinMainnetGenesis: litecoinChain,
}


What is chainhash?

Quote


Roll Eyes


▄▄▄████████▄▄▄
▄██████████████████▄
▄██████████████████████▄
██████████████████████████
████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
████████████████████████████
██████████████████████████
▀██████████████████████▀
▀██████████████████▀
▀▀▀████████▀▀▀
   ███████
██████████
██████████
██████████
██████████
██████████
██████████
██████████
██████████
██████████
██████████
██████████
███████
BTC  ◉PLAY  ◉XMR  ◉DOGE  ◉BCH  ◉STRAT  ◉ETH  ◉GAS  ◉LTC  ◉DASH  ◉PPC
     ▄▄██████████████▄▄
  ▄██████████████████████▄        █████
▄██████████████████████████▄      █████
████ ▄▄▄▄▄ ▄▄▄▄▄▄ ▄▄▄▄▄ ████     ▄██▀
████ █████ ██████ █████ ████    ▄██▀
████ █████ ██████ █████ ████    ██▀
████ █████ ██████ █████ ████    ██
████ ▀▀▀▀▀ ▀▀▀▀▀▀ ▀▀▀▀▀ ████ ▄██████▄
████████████████████████████ ████████
███████▀            ▀███████ ▀██████▀
█████▀                ▀█████
▀██████████████████████████▀
  ▀▀████████████████████▀▀ 
✔️DICE           
✔️BLACKJACK
✔️PLINKO
✔️VIDEO POKER
✔️ROULETTE     
✔️LOTTO
Pages: « 1 2 3 4 [5] 6 7 »  All
  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!