Gold collapsing. Bitcoin UP.

sgbett

Active Member
Aug 25, 2015
216
786
UK
Too much logic sgbett :)
Sorry Logic is all I have ;)
[doublepost=1457540460][/doublepost]
Great post. And they banned you for that? BashCo back to his old tricks. Shameful.
sorry banned was probably the wrong word. I found that the post was visible in my account but deleted everywhere else. I reposted without the link so must have been that that triggers the 'hiding' function whatever it is
 

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,994
@sgbett

you might want to consider reporting your censor to the reddit admins since we know something has changed over there most likely a warning notice to theymos from them.
 
  • Like
Reactions: majamalu and Norway

bluemoon

Active Member
Jan 15, 2016
215
966
@sgbett: Ask the mods why it was deleted. Complain you were not informed or given a reason.

It may not even be the link and if it is they should justify it, even according to their tortured logic.

Yesterday I had a minor comment reinstated after changing a link's format to np. I got a lot of aggressive and condescending garbage from the moderator who moaned at me for persisting with posting.
 

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,994
  • Like
Reactions: Norway

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,994
@theZerg

so Gavin's headerless mining proposal of yesterday enforces the concept in your SPV mining paper by limiting validation time to 30 sec beyond which the block is discarded in favor of the previous correct, is that your understanding?
 
  • Like
Reactions: Norway and AdrianX

sickpig

Active Member
Aug 28, 2015
926
2,541
I wrote a "round-up" of onchain scaling techniques. Might be very helpful to those planning the on-chain scaling e-conference and other interested people. Please read and tell me what I've forgotten:
http://effluviaofascatteredmind.blogspot.com/2016/03/the-bitcoin-on-chain-scaling-landscape.html

(sorry in advance, of course I know my own proposals best)
just a few notes regarding ideas attribution:

SegWit is mainly a Pieter Wuille idea, Luke-jr found out a way to introduce it via soft-fork.

Sidechains in the one way peg incarnation is Adam Back's idea, Maxwell add a way to make it two way (new op code needed)

Lightning Network white paper was written by Joseph Poon and Thaddeus Dryja, there are at least two teams working on two separate implementation.

one last thing about SegWit:

AFAIK non validating nodes don't need to download the signature parts, whereas validating nodes could drop the signature after validating it.

So in the former case there is a reduction both in terms of bandwidth and storage. In the latter only storage will be reduced, iif the node operator decides to prune signatures after the validation step.

from segwit bip:

Transmission of signature data becomes optional. It is needed only if a peer is trying to validate a transaction instead of just checking its existence.
 
Last edited:

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,994
Got my first RBF related warning. I imagined myself as a Starbucks cashier saying WTF?


[doublepost=1457544103][/doublepost]i've dodged the massive squeeze attempt for now. i was one small wave too early but looking good:


[doublepost=1457544618,1457543788][/doublepost]
just a few notes regarding ideas attribution:

SegWit is mainly a Pieter Wuille idea, Luke-jr found out a way to introduce it via soft-fork.

Sidechains in the one way peg incarnation is Adam Back's idea, Maxwell add a way to make it two way (new op code needed)

Lightning Network white paper was written by Joseph Poon and Thaddeus Dryja, there are at least two teams working on two separate implementation.

one last thing about SegWit:

AFAIK non validating nodes don't need to download the signature parts, whereas validating nodes could drop the signature after validating it.

So in the former case there is a reduction both in terms of bandwidth and storage. In the latter only storage will be reduced, iif the node operator decides to prune signatures after the validation step.
probably should mention that those old non validating nodes get demoted to SPV level security.
 
  • Like
Reactions: Norway

Roger_Murdock

Active Member
Dec 17, 2015
223
1,453
If that was true then every alt coin and even bitcoin itself would be hopeless. Bitcoin is itself a fork from FED dollars and alt coins are forks to new genesis blocks. The reality is every single one, including Bitcoin, has taken a fork now and gain market share approach. That is exactly the path Bitcoin itself took.
Well I happen to be pretty skeptical of altcoins. And I don't think you can say that Bitcoin is a "fork" from dollars. The dollar isn't an open-source protocol that can be forked so starting a brand new ledger was the only real option. Re: Bitcoin's prospects, it's true that the incredible importance of network effects gives established fiat currencies one big advantage over Bitcoin. But I still think Bitcoin has a decent shot at prevailing in the end based on its superior properties. Fiat can't become more reliably scarce. Gold can't become more transactionally convenient. Bitcoin can increase the size of its network effect through continued adoption.
 

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,994
@sickpig

b/c the RBF documentation says that receivers/merchants will get this type of warning. what's interesting is that i'm the sender in this case using Mycelium, so that's a bit confusing. but the pmt is going thru Bitpay so they're probably broadcasting the warning to both sides of this tx, i don't know. also, i've never seen this type of warning before and am assuming Mycelium/Bitpay has upgraded to 0.12.

"btw, as your Starbucks cashier, you must now go and stand over in the corner as your tx has not confirmed for over 35 min now. nvm your work."


[doublepost=1457545569][/doublepost]@sickpig

ok, maybe it's not RBF related. maybe it's b/c i made a parent tx minutes before this one that hasn't cleared yet. over at Tradeblocks, the tx spam attack may be picking up again.
 
  • Like
Reactions: Norway

jl777

Active Member
Feb 26, 2016
279
345
@cypherdoc, Thanks! I threw it up on reddit based on the positive feedback here...
If there isnt any earlier proposal for interleaving blocks (I described it several pages back), maybe it can be on the list?

The idea is to have 10 chains all in parallel, offset by 1 minute each.

Ordering of blocks are based on the order of each parallel chain

The one issue is that provision needs to exist for a tx that is valid in a later interleave, but it is spent when an earlier interleave comes in. And of course the issue about mining rewards, txfees, penalties, etc.

This provides 10x the capacity and can be used with all the other methods I have seen. Also, it offers a way to get 1 minute latency by the user submitting 10 different tx, each deterministically goes to a specific interleave based on vin

There is no whitepaper as it is rather a simplistic method, but I made a thread for it: https://bitco.in/forum/threads/10x-boost-of-tx-capacity-via-interleaved-blocks-orthogonal-with-other-methods-and-can-be-combined.956/

James
[doublepost=1457545703][/doublepost]
@sickpig

b/c the RBF documentation says that receivers/merchants will get this type of warning. what's interesting is that i'm the sender in this case using Mycelium, so that's a bit confusing. but the pmt is going thru Bitpay so they're probably broadcasting the warning to both sides of this tx, i don't know. also, i've never seen this type of warning before and am assuming Mycelium/Bitpay has upgraded to 0.12.

"btw, as your Starbucks cashier, you must now go and stand over in the corner as your tx has not confirmed for over 35 min now. nvm your work."


[doublepost=1457545569][/doublepost]@sickpig

ok, maybe it's not RBF related. maybe it's b/c i made a parent tx minutes before this one that hasn't cleared yet. over at Tradeblocks, the tx spam attack may be picking up again.
zeroconf CANNOT work when blocks are full, RBF or no RBF
 
Last edited:
  • Like
Reactions: bluemoon

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,994
@jl777

when one prunes a full node, say prune=1000, what's left? the 1000 near the tip of the chain or the 1000 from the genesis block? i'd assume from the tip. if that's the case, does your node continue to verify tx's and relay blocks in that 1000?
 

jl777

Active Member
Feb 26, 2016
279
345
I am only a user of 0.12, so can only guess. Certainly it would be possible for it to relay up to the prune width, but not sure if that is implemented. It might be only relaying new blocks. I know it continues to validate
 

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,994
i mean, there really can't be a more tacit admission of whom Luke Jr cowtows to, can there? we are NOT imagining things when we say there is a COI:

 

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,994
hey brg444! glad to see you've come around!:

proslogion [11:14 AM] Otoh, didn't the drum roll on the sidechain issue long before?
I mean who today honestly dislike sidechain
Not even Armstrong
brg444[11:14 AM] cypherdoc :simple_smile:
alp [11:14 AM] peter todd pointed out some security flaws
there are real arguments to be made
brg444 [11:15 AM] well I've come around to the idea that some of the criticism of them is somewhat fair
proslogion [11:15 AM] Yeah i know, but i only talk about those who are relevant
brg444 [11:15 AM] I think the paper was.... somewhat premature
proslogion [11:15 AM] Well, bottomline is, fed sidechain works to everyone's satisfaction
So at least you need to call out the merged mined one
brg444 [11:16 AM] right
I think it's fair criticism to say that the way it was presented seemed to suggest they had nailed even the MM model when by all accounts it has yet to be completely figured out
fed sidechains are awesome though
alp [11:20 AM] only trouble with them is the federation
but still, can do a lot of good.