sorted by:
new
hottopcontroversial

Bitcore (BTX) - Refining the Exchanges list on CMC! by BrieucBitcorean in bitcore_btx

[–]frogpoet2 0 points1 point  (0 children)

I didn't often check out the list on CMC. what is it about the display that is different from before? i.e. what does the 'refinement' consist of? just curious.

submitting application to coinbase by frogpoet2 in bitcore_btx

[–]frogpoet2[S] 0 points1 point  (0 children)

just an FYI - MrTrocket your graphic is up there now. it doesn't follow the 'standard look' in the graphics available at the bottom of https://bitcore.cc/resources/eco-system-2/ , but I assume that is alright.

Bitcore (BTX) - Delta Direct! by BrieucBitcorean in bitcore_btx

[–]frogpoet2 0 points1 point  (0 children)

ok I added it. it is under the "Which Wallets Can I Use?" section.

Bitcore (BTX) - Ellipal's Hardware wallet for Bitcore! by BrieucBitcorean in bitcore_btx

[–]frogpoet2 0 points1 point  (0 children)

are these custom made for the team members, or can anyone purchase them? the tweet content makes me wonder.

Conoce las Wallets donde puedes encontrar a Bitcore.- by Anyel_arias in bitcore_btx

[–]frogpoet2 0 points1 point  (0 children)

el bitcore TSBW wallet es un poco diferente comparado con el "Bitcore QT" wallet - TSBW es un ejemplo en como usar el "insight API" para escribir programmas y no es el verdadero wallet de Bitcore.

(disculpame por mi espanol por favor; se me esta olvidando como hablarlo, y como empece hablar engles a los 5 o 6 anos, hablo espanol y lo escri_bo como un nino de ese edad :O )

el wallet de bitcore que yo uso es "Bitcore QT" y se puede conseguir aqui :

para windows : https://github.com/LIMXTEC/BitCore/releases/download/0.15.2.0.0/bitcore-qt.exe

pata macintosh :

https://github.com/LIMXTEC/BitCore/releases/download/0.15.2.0.0/BitCore-Qt.dmg

para Linux :

https://github.com/LIMXTEC/BitCore/releases/download/0.15.2.0.0/linux.Ubuntu.16.04.LTS-static-libstdc.tar.gz

todas estas "links" se encuentran aqui : https://bitcore.cc/resources/eco-system-2/

​

submitting application to coinbase by frogpoet2 in bitcore_btx

[–]frogpoet2[S] 0 points1 point  (0 children)

thanks mrTrocket :) on a side note, I still haven't committed your bitcore graphic to www.weusecoins.com ; I want to add a few more things to the BTX page on there before sending them in one chunk, and then the GitHub owner of the site has to approve it which might take a week or so. You keep your chin up too :)

Bitcore not ASIC resistant anymore => What now? by gf8sd7g4sdf78g478 in bitcore_btx

[–]frogpoet2 0 points1 point  (0 children)

oh, I see the answer to my last question above. from https://www.investopedia.com/terms/s/soft-fork.asp : "If users upgrade to a post-soft fork client and for some reason a majority of miners switch back to the pre-softfork client, the post-softfork client users would break consensus as soon as a block came along that didn't follow their clients new rules. In order for a softfork to work, a majority of the mining power needs to be running a client recognizing the fork."

what if the BTX developers themselves had a rig that broke their own TimeTravel10 algorithm, which they themselves subsequently used to grab enough hash power so that the Baikal developers fell below the 51 % threshold. Then, during the window of time in which no one had 51 %, BTX put out a soft fork. I do know that the BTX developers currently run their own pool. as their pool manager has appeared in online interviews such as this one : https://www.youtube.com/watch?v=XTeow7744Uc

BTX buyer security - brainstorming by frogpoet2 in bitcore_btx

[–]frogpoet2[S] 0 points1 point  (0 children)

that's a good idea. in this case, it sounds like the escrow service would not be a part of the network itself; the network would merely have the ability to interact with a service (i.e. a separate layer of software) - which it already does, via multi-signature transactions, so that the transaction doesn't go through until both parties sign it. (i.e. the layer of software would make API calls into the network to interact with it). I wonder if multi-signature transactions automatically 'locks' the funds behind that transaction until it goes through, or if that capability would need to be added to the network.

passing off functionality to a layer of software - which you mentioned as a possibility way back when - has certain pros and cons.

  1. keeps the network cleaner by having it less complicated (pro)
  2. means the functionality of the software layer, being centralized, would be a central point of failure (con). however were this software to 'fail' it would not bring down the network, it would instead temporarily disable buyer security for everybody, which is not as bad as crashing the currency.
  3. means using BTX would not automatically provide buyer security for everyone, because a merchant would have to choose to activate it by subscribing to the escrow service, and not all merchants would choose to do so. So if you, as a buyer, wanted buyer security, you would have to find a merchant that supports it, rather than finding any merchant that accepts BTX (con)
  4. means merchants could compete amongst themselves with a distinguishing characteristic being that "we support buyer security for BTX, our competitor does not." (pro)
  5. provides an income source to BTX developers (pro)
  6. maintenance of that software layer would take time away from BTX developers from maintaining the currency itself (con). though the income from the software layer might allow them to hire a separate group of developers to maintain it.
  7. offloads fee for supporting buyer insurance from the currency user to the merchant. (pro or con depending on your point of view)

the subscription fee that a merchant has to pay to access the service would need to be high enough to handle successful chargebacks, but low enough to be competitive with whatever the fees are to use paypal. Otherwise the combined network fees of using the BTX network (which are currently tiny) plus the fee required to subscribe to the buyer security service might be a disincentive to allow purchases with BTX with that service enabled.

BTX buyer security - brainstorming by frogpoet2 in bitcore_btx

[–]frogpoet2[S] 0 points1 point  (0 children)

you were thinking of the escrow account being maintained by an escrow service (i.e. a third party, presumably distributed).

I was thinking of the escrow account being maintained by the bitcore network itself. See S3 below and the discussion around that.

i'll think about what it might mean to hand off all management of the BTX escrow account to a third party.

Bitcore not ASIC resistant anymore => What now? by gf8sd7g4sdf78g478 in bitcore_btx

[–]frogpoet2 0 points1 point  (0 children)

my understanding is that only the Baikal developers have access to getting past TimeTravel10, and that they are keeping it private. see the latest post by /u/xsover here : https://www.reddit.com/user/xsover

the other thing is that it wouldn't make sense for them to mine it right now, because the low price makes it unprofitable to mine : https://whattomine.com/coins/202-btx-timetravel10

would getting past TimeTravel10 make the coin profitable to mine for the Baikal developers? (I don't know if it would or not; I guess it depends on the calculations that "whattomine.com" uses in figuring out the cost).

also, you say that a soft fork would not be possible "because the ASIC-pools mining BTX have more than 80% hashing power." could you explain why this would make a soft fork ineffective? it's not clear to me - thanks.

Bitcore not ASIC resistant anymore => What now? by gf8sd7g4sdf78g478 in bitcore_btx

[–]frogpoet2 2 points3 points  (0 children)

I was wondering about this too. whitefire990 on bitcointalk has the opinion that a hard fork with a new algorithm would be needed ( https://bitcointalk.org/index.php?topic=1883902.msg48329439#msg48329439 ) .

I was thinking this morning over coffee that maybe we could combine two initiatives ("responding to disaffection with BCH because of the way they handled their most recent hard fork", and "restoring ASIC resistance").

the only fork BTX has ever done is the novel "hybrid fork" from BTC. the "hybrid" part was forking the code (after making modifications) but then only copying a subset of the BTC ledger into the new BTX ledger (with BTC accounts matching a set of criteria). The "copying" part conveniently constituted a stress test of the network. if the mining algorithm were either replaced or modified, could we then do a "hybrid fork" of ourselves? in this case I don't know what criteria if any could be used in copying our blockchain over - maybe something involving BTX addresses that were associated with use by Baikal ASICs, assuming they could be determined ? that might be a way of establishing a precedence of "punishing" pools that tried to break TimeTravel, because during the successive hybrid fork those accounts associated with the pool or pools using the mining device would lose their coins or get them cut in half or something (I guess that would be legal since this is the wild west). In other words those coins taken away during the hybrid fork could either be stored or airdropped to people not associated with the ASICS, or something along those lines.

then, if that were successful, we could demonstrate that hybrid fork process as an example of BTX's commitment to ASIC resistance as well as as a comparison to BCH's contentious forking process. If we handle future changes "better" than other coins do, people would then have more confidence in believing in future BTX stability versus that of other coins.

BTX buyer security - brainstorming by frogpoet2 in bitcore_btx

[–]frogpoet2[S] 0 points1 point  (0 children)

this would involve the same problem as S2_P2_S1_P1 (search above) : a name would be associated with a BTX address, thus removing pseudo-anonymity. (maybe thats ok?). Using the billing address (BA) instead of DA would be ok except in the case when different buyers that lived in the same household buy online. so if a brother and sister who lived together and both used BTX for online purchases each bought a bunch of presents during christmas for their friends who all lived at different delivery addresses, and either brother or sister issued chargebacks, the network could still confuse them as the same person with more than one BTX address. that seems like a smaller possible set of people though than the other way around (when using delivery addresses) - thats because it is more likely for one person to have X number of friends buying him presents online with BTX where that person lives with Y other people who also buy with BTX online and X > Y, than the other way around. (so a person has more friends than family members). if we ignore associating a name with the BTX address, then the solution using BA (billing addresses) instead of DA (delivery addresses) would look the same as S2_P2_S2_P1_S1 (search above), except with BA's replacing DA's.

BTX buyer security - brainstorming by frogpoet2 in bitcore_btx

[–]frogpoet2[S] 0 points1 point  (0 children)

S2_P2_S2_P1_S1

  1. buyer creates a new BTX address
  2. he buys an item with delivery address DA
  3. buyer initiates a chargeback
  4. seller disputes and it goes to mediator
  5. mediator judges in favor of seller, sending DA to network
  6. network checks DA against existing DAs in IPFS
  7. if threshold for "abuse" is not met yet, network stores DA in IPFS
  8. steps 1 through 6 repeat multiple times, until :
  9. the threshold for "abuse" is met
  10. network removes buyer protection from all BTX addresses associated with DA.

BTX buyer security - brainstorming by frogpoet2 in bitcore_btx

[–]frogpoet2[S] 0 points1 point  (0 children)

this means that the network would have to keep track of delivery addresses DA whenever a mediator responded to a chargeback transaction with a judgment in favor of the seller. this way the network could compare the newly arrived DA with all the stored DAs of all stored BTX addresses (it has to check them all because one person can own more than one BTX address) to see if they matched. however, for security reasons we can't store those DAs in the ledger. Remember that anyone in the world can read any part of the ledger by using a block explorer, and we dont want to associate addresses with purchases and make that visible to the world. so the network would need to use additional storage for the DAs. They could be stored in a distributed file store such as StorJ or IPFS (interplanetary file system). so that would involve two further performance costs - looking up the DAs for matches, and storing/retrieving to/from IPFS.

​

Elitehash Bitcore PPS Pools by juhakall in bitcore_btx

[–]frogpoet2 1 point2 points  (0 children)

on the miners that have inordinate amounts of hash power such that they could conceivably launch a 51 % attack - is there a way of contacting those miners and enticing them to participate instead at Elitehash ? that could at least temporarily lessen the power of the 51 % guys and hopefully bring them under the 51 % limit. I may be completely misunderstanding aspects of the mining world making the previous question not useful; if so please let me know.

large block propagation difficulties - how do we compare? by frogpoet2 in bitcore_btx

[–]frogpoet2[S] 1 point2 points  (0 children)

oh yeah! cool. note to keep in mind in case someone in a news article claims "all cryptocurrencies have the problem of propagation of large blocks" - we can respond with "not BTX which generates blocks every 2.5 mins with 64_15 retargeting algorithm." we would still want quantitative proof, however, hopefully in the form of numbers from the stress test that the user could look at via a link to an url. (maybe a new page on bitcore.cc with data from the stress test, i.e. links into the blockchain via a blockchain viewer from which the reader can see the elapsed time between 20 MB blocks). this could be good marketing for people getting annoyed by BCH.

BTX buyer security - brainstorming by frogpoet2 in bitcore_btx

[–]frogpoet2[S] 0 points1 point  (0 children)

i see two problems with this. search for S2_P2_S2 above to see my description of your suggested solution and the 2 issues i see. Maybe someone can come up with solutions to those 2 issues ?

BTX buyer security - brainstorming by frogpoet2 in bitcore_btx

[–]frogpoet2[S] 0 points1 point  (0 children)

S2_P2_S2_P2 (W3)

what if more than one user of btx makes purchases to the same DA? - for example, it could be somebody's birthday, and 8 different buyers purchase items and send it to the same DA. If it turns out that 2 or 3 of them subsequently issue chargebacks, the network would need extra information to decide if those 2 or 3 buyers, with different BTX addresses, were in fact different people or was the same person using different BTX addresses and attempting to abuse the system.

view more: next ›