Aunque pienso que el acercamiento de @bit de señalar abajo este poste y de llamarlo "FUD" es un abuso indignante de su "peso" en la plataforma del steemit, quizás no debería ser demasiado sorprendido. En China, el gobierno a menudo cree que la censura es la solución ideal para "mantener a las masas en línea". Supongo que @abit suscribe este punto de vista también, a pesar de que va en contra de todo lo que STEEMIT se supone que representa.
Como tal, resulta @abit , @pc, y yo estamos bien y mal sobre lo que está pasando aquí. Sin embargo, creo que habría sido mucho más productivo y eficiente para trabajar juntos en la solución del problema, sin todo el "drama" @abit eligió traer a la mesa.
Una vez que entendí lo que realmente estaba pasando, también era capaz de reproducir fácilmente este comportamiento en el testnet también. Sobre @abit repetidamente haciendo hincapié en "errores de redondeo", decidí experimentar un poco más para ver si tal vez estaba subestimando cuán grandes podrían ser estas discrepancias, incluso con emparejamientos aparentemente "razonables". Simplemente no tiene sentido para mí cómo se aplicaría en esta situación. Pero si la división se utiliza de forma no óptima, es cierto que los errores de redondeo pueden agravarse muy rápido. Como un ejemplo simple, 0.01 es sólo un centavo. Pero si se invierte, 1 / 0,01 = 100 y 1 / 0,02 = 50.
Pero, ¿por qué este tipo de comportamiento importa aquí? Tenemos una oferta para asistir. Sin embargo, de alguna manera estamos viendo rellenos que llegan a precios mucho más altos. ¿Cómo es esto un error de redondeo ???
Voy a entrar y decirte.
El "problema", al menos para que la comunidad decida si lo consideran un "problema", es que usted no sólo está "comprando", sino que está "Comprando al menos" . Ese es el lugar donde los "errores de redondeo" se están acumulando.
Tomemos el siguiente ejemplo. Digamos que hay una oferta de 4,50 y, por accidente, ofrezco 4,60 por 10 en lugar de 4,50 por 10. La mayoría de nosotros no creo que sea un gran problema, sólo estaremos recibiendo 10 a 4,50 cada uno. Eso NO es cómo bitshares actualmente funciona. Lo que obtendrás en cambio es 10.0178 a 4.50.
Y si ese precio 4,50 no "redondea" uniformemente, la cifra puede haber sido mayor, en algunos casos mucho mayor. Pero en la mayoría de los casos @abit y @pc probablemente tengan razón. Esperemos que debería equilibrar de manera relativamente uniforme, excepto para ciertos casos de "franja" ...
Tales como comprar 0,01 en 8,17 en lugar de 8,16138. Eso parece ser un problema. Comprar 0.0002 HERO en 925 frente a la oferta 919 también parece ser un problema, porque bitshares no puede cuantificar correctamente el ajuste de tamaño frente a la oferta actual.
Ahora vamos a ver un ejemplo realmente extremo de este juego en el TESTNET con lo que debería ser sólo un "pequeño" orden ... ¿Qué pasa si quiero comprar 1.5 INTELLIGUYPIZZA en 4.50 TEST, pero por accidente ingresé 345 en su lugar. Sí, estoy al tanto de la "GUI warning". Pero ese no es el punto aquí. La oferta es de 4,50, y hay mucho disponibles. Por lo tanto, no hay problema ... en su lugar, voy a obtener mi 1,5 a 4,50 en lugar de 345, ¿verdad?
¡INCORRECTO!
Esto es lo que realmente va a conseguir ... compró 113 INTELLIGUYPIZZA en 4.50 TEST / INTELLIGUYPIZZA. Si el tamaño versus el precio no coincide (por lo tanto, el "error de redondeo"), la ejecución también puede haber tenido lugar a un precio ligeramente superior a 4,50 también.
Pero, por supuesto, también acaba de comprar 113 en lugar de los 1,5 que estaban esperando . Personalmente, no creo que esta sea la forma correcta en que debe manejarse. Me hubiera esperado 1,5 a 4,50, y eso es todo.
Https://testnet.bitshares.eu/account/scalp-hole1/overview/
Pero ¿qué pasa con los locos WHALESHARE compra ?!
Ahora, mientras que todo esto parece responder a la mayoría de los casos que me encontré con, no parecía dirigir correctamente el WHALESHARE_BTS comprar un 40% más alto que la oferta interior. A MENOS QUE, por supuesto, este "ajuste de tamaño" esté dirigido a la LEG NO DECIMAL para el ajuste! Pues bien, eso debería ser fácilmente comprobable en el TESTNET. Así que creé un nuevo activo NO DECIMAL llamado WHALEHOLE. Y este esfuerzo no decepcionó. Te daré las capturas de pantalla, y te dejaré hacer lo que quieras .
Https://testnet.bitshares.eu/market/WHALEHOLE_TEST
Una vez más, puede que no haya conseguido la causa exacta muy correcta la primera vez, pero lo declaré tanto, y agradezco mucho a aquellos que apoyaron mi posición a lo largo de esta "experiencia". Mi único objetivo aquí era informar a los usuarios de un problema crítico y ayudar a hacer bitshares más seguro y más "amigable" para todos los que utilizan la plataforma. Puede que tenga sus peculiaridades, pero en mi opinión, sigue siendo la mejor solución de comercio descentralizado que existe actualmente. Si @abit hubiera elegido un camino diferente para trabajar juntos, en vez de ir inmediatamente a la yugular, tal vez podríamos haber trabajado de manera más productiva y con menos sentimientos.
Pero, al menos estoy feliz de que ahora todos entendamos mejor lo que está sucediendo exactamente. Si esta es la forma en que la comunidad cree que la red de bits de bits debe funcionar, grande. Si no, bueno, tal vez haya una "discusión" que se pueda tener después de todo ...
Bueno, este es un doozy real, incluso junto a los otros BitShares "característica" que escribí acerca de unas semanas atrás, lo que sugiere ser muy cuidadoso cuando el comercio de 2 fichas no decimal entre sí en el DEX BitShares, a fin de que termine pagando Mucho más de lo que esperaba para sus fichas .
Y mientras que usted debe siempre tener cuidado de chequear (triple-cheque?) Las órdenes que usted entra, tenga cuidado extra de no poner una oferta que cruza sobre la oferta (es decir, no intente "barrer" las ofertas) . Con la mayoría de los sistemas de negociación, naturalmente esperaría que su oferta de cruce para emparejar con la oferta más baja. Sin embargo, dependiendo del escenario, la red de bitshares puede simplemente llenar su pedido en el precio ingresado, no importa cuánto por encima de la oferta es " dedos de grasa "! 😱
Este "viaje" comenzó cuando noté algunos oficios que habían ejecutado directamente a través de una pared de órdenes de venta. Aquellos a los que me lo mencioné por primera vez en los Hangouts de BitShares / Beyond Bitcoin parecían muy escépticos, incluso podrían suceder, y ofrecieron sugerencias como "quizás todas las ofertas se retiraron momentáneamente". Cryptofresh.com es una herramienta fantástica para explorar la cadena de bits y el seguimiento de las órdenes, ejecuciones, contrapartes, etc Sin embargo, un análisis más detallado de estos oficios no reveló nada de la clase que tiene lugar. La mayoría de las ofertas eran simplemente órdenes permanentes, sentado en el libro durante horas o incluso días. Y si alguien intensificó con un BID que superó la OFERTA, que inmediatamente se llena con el "dedo gordo" precio!
Francamente, estoy sorprendido de que nadie haya intentado corregir este problema, especialmente teniendo en cuenta que he encontrado referencias que rodean el problema desde 2015, cuando BitShares 2.0 fue el primero "desencadenado". Me sentí especialmente confundido cuando todas las órdenes de cruce sobrevaluadas que puse en el testnet de bitshares cruzaron perfectamente, exactamente como se suponía. ¿Qué podría estar causando que mi experiencia en el mundo real (y muchos otros desafortunados) fuera tan diferente de la testnet? ¿Fue un problema de interfaz gráfica de usuario, o un problema bloqueado?
Uno de mis pensamientos anteriores era que quizás la GUI era responsable de asegurarse de que una orden no sobrepase. Sin embargo, tampoco pareció ser el caso. Sin embargo, antes de llegar a esa conclusión, he puesto órdenes excesivas desde la GUI web y la GUI de la aplicación, con resultados idénticos ...
Y para estar seguro, utilicé el excelente programa Fiddler de Telerik (el proxy de depuración web gratuito) para monitorear la conversación websocket y averiguar qué está pasando. Bajo y behold, pude confirmar que el overpay se estaba enviando al servidor, y estábamos recibiendo el ajuste de precios adecuado después de todo! Así que definitivamente es un problema bloqueado ...
outgoing: {"method":"call","params":[3,"broadcast_transaction_with_callback",[181,{"ref_block_num":39315,"ref_block_prefix":1899533150,"expiration":"2017-07-14T22:05:39","operations":[[1,{"fee":{"amount":"100","asset_id":"1.3.0"},"seller":"1.2.3252","amount_to_sell":{"amount":"540000","asset_id":"1.3.279"},"min_to_receive":{"amount":"100","asset_id":"1.3.280"},"expiration":"2022-07-14T22:05:17","fill_or_kill":false,"extensions":[]}]],"extensions":[],"signatures":["20385f468195f7c5270984b38ed6f3855ee257d13b3914b636f690c32cb50661785ed539e60068a8bdbed8cc6fea0d96e3d1cfa134fbca0bcf26dec30ae17c3849"]}]],"id":181}
incoming: {"id":181,"jsonrpc":"2.0","result":null}
incoming: {"method":"notice","params":[50,[[[[4,{"fee":{"amount":2,"asset_id":"1.3.280"},"order_id":"1.7.69096","account_id":"1.2.3252","pays":{"amount":540000,"asset_id":"1.3.279"},"receives":{"amount":108,"asset_id":"1.3.280"}}],[0,{}]],[[4,{"fee":{"amount":0,"asset_id":"1.3.279"},"order_id":"1.7.69074","account_id":"1.2.3246","pays":{"amount":108,"asset_id":"1.3.280"},"receives":{"amount":540000,"asset_id":"1.3.279"}}],[0,{}]]]]]}
Para resumir ese bit de gobbly-gook, lo que está viendo aquí es que traté de pagar en exceso con una oferta de 54 frente a una oferta de descanso en 50. El orden saliente muestra "cantidad: 540000" versus "min_to_receive: 100".
El relleno devuelve "cantidad: 540000" versus "paga: 108".
540000/108 = 5000/100 (para el decimal) = 50 , o exactamente lo que debería ser!
Pero, ¿qué diablos, te daré sólo un ejemplo más en el que pague en exceso al comprar un HERO versus BTS en la red de bits en directo . ¿No es divertido ? Bueno, solo espera ... ¡está a punto de conseguir un FUNNER ! Jajaja
Ofrecen sentarse a 919 bts, pero tuve el "placer" distinto de COMPRAR en 925 bts!
GRAN, usted hizo su punto ... ¿qué está sucediendo realmente aquí?
Mi pensamiento original era que el problema era marginal-llamada relacionada. Como se describe en la parte superior de este post, yo era incorrecto en esa evaluación, por lo que he eliminado esta sección de la publicación y defer a volver a mi explicación revisada.
El "Viaje" a la Solución del PROBLEMA ...
Para rastrear la "fuente" de este problema, elegí cargar el código fuente bitshares en Visual C ++ y paso a través de ver exactamente lo que estaba pasando. Después de instalar VC 2013 y VC 2015 (que había logrado evitar hasta ahora) , e intentando seguir múltiples pasos para conseguir que funcione, bueno, no hace falta decir que simplemente no pude averiguar lo que estaba perdiendo Para conseguirlo que va ...
Error C2027 use of undefined type 'std::_Get_function_impl<_Fty>' graphene_app C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\functional 472
Alguien tiene una pista de lo que estoy perdiendo aquí?
Independientemente, algunos de ustedes pueden recordar mi post hace unos meses, " EOS: ¿Cuál es su mejor proveedor de Cloud Bang-for-the-Buck? ". Y después de perder mucho tiempo en Visual Studio, decidí que esta podría ser una gran oportunidad para dar una oportunidad a scaleway.com. El peor caso es una mierda, el mejor caso, bien quién sabe ... pero ¿cómo podría realmente ir mal con sus 3 euros / mes VM ?! Tengo 2 x86 64-bit Intel Atom núcleos en 2.4ghz, 2gb de memoria, 50gb SSD y 200Mbit de ancho de banda sin medir. He configurado una gotita Ubuntu 16.04 con un escritorio xfce ( accedido a través de x2go ) , y francamente, ha sido sólido desde entonces! Tengo que decir, por 3 euros al mes, que realmente no te puedes equivocar. Y bueno, si este post lo hace bastante bien, tal vez pueda "derrochar" Por su versión de 10 euros / mes con 8gb y 6 núcleos! 😁 (es broma ...)
El mayor problema fue que la base de código tomó mucho tiempo para compilar, pero eso siempre parece ser el caso con grandes proyectos C ++, y mientras que una gotita más grande probablemente ayudaría algo, muchos otros ejecutar servidores testigos, nodos steem, etc. También se quejaron de tiempos de construcción largos, a pesar de desplegar gotitas mucho más potentes.
Sin embargo, finalmente lo conseguí todo ... corriendo y depurando bitshares-core a través del excelente CodeLite IDE . Primero intenté usar el CodeBlocks IDE , pero seguí golpeando una pared. Tal vez yo estaba simplemente falta algún ajuste simple en alguna parte, pero con CodeLite, estaba bastante en marcha y corriendo mi primer intento!
EOS también ?!
Como una ventaja añadida, y especialmente oportuna como @dan acaba de anunciar el "EOS Desarrollo Sneak Peek para los desarrolladores muy temprana" , incluso logré obtener un testnet EOS en funcionamiento y en la misma gotita !
Había algunos golpes con la versión actual en ese momento. También tuve que crear un archivo de intercambio, porque 2GB no lo cortó para EOS para compilar. Sin embargo, después de crear un archivo de intercambio de 6 GB , y una vez que el equipo EOS corrigió los problemas con la configuración del muelle, era más o menos suave navegar desde allí. Para aquellos que quieran construir un testnet EOS sin usar docker, @clayop escribió un artículo "paso a paso" que describe cómo hacerlo .
Para aquellos interesados, es posible que desee leer este hilo de discusión que describe algunos de los problemas que surgieron. Huelga decir que ahora también estaba "minando" los bloques testnet de EOS! :RE
Finalmente...
Es difícil decir cuánto tiempo puede ser antes de que este problema se corrige, o incluso si se corrige. Algunos pueden ver esto como una "característica", en contraposición a un "patrón inesperado de comportamiento" (sin duda aquellos que buscan aprovechar esta "laguna") . Como tal, postularía que la confianza en el sistema y la forma en que se espera que sea eficaz es fundamental para atraer más liquidez y apoyar los objetivos de crecimiento a más largo plazo de la plataforma.
Independientemente, siempre es prudente para comprobar que sus precios límite no cruza el mercado , o bien puede terminar pagando en exceso, en algunos casos muy dramáticamente! Gran parte de esto es una tecnología de vanguardia, y seguramente habrá problemas que todavía se plantean aquí y allá. Simplemente tome el tiempo de inactividad más reciente de bitshares una semana o así. @dan rápidamente resolvió el problema, a pesar de todo el trabajo que está haciendo en EOS . La red volvió a subir, y el mundo siguió adelante. "Preocupación y pánico" sobre el "futuro de la red" fue en su mayoría infundado.
Con los años, he sido testigo de innumerables veces cuando la Bolsa de Chicago, la Bolsa de Nueva York, NASDAQ, y otros mega- intercambios exhiben tiempo de inactividad graves, así, por no hablar de algunos realmente whopper orden de coincidencia de líos. Como siempre, la "Ley de Murphy" se aplica universalmente ... Si algo puede salir mal, saldrá mal. Como pasa
Sólo sé consciente, y estar a salvo allí mis amigos! 🙂
ACTUALIZACIÓN: Al parecer, mi mensaje ha causado un poco de revuelo en la comunidad de bits, y me alegro de que por lo menos tengo la discusión iniciada, y que el tema ahora se está estudiando más en serio. Para aquellos interesados en seguir:
BitSharesTalk Tema: https://bitsharestalk.org/index.php/topic,24715.0/all.html
GitHub Problema: https://github.com/bitshares/bitshares-core/issues/338
Como siempre, agradezco su upvote, su seguimiento y todos sus comentarios!
thas good
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit