I'm an angel of common sense
99% of forum members are very far from understanding many important details. They can't "verify signatures" but have to trust instead (light-client model in social communication). This is dangerous in case we talk about privacy. I can't promise to read the thread but you can ping me with PM.

It will be very interesting to see details about relative CPU / GPU performance of light version and native C++/asm hash rate on actual embedded CPU.

Hardfork is possible only in case people agree with. It's easy to change PoW with low hashrate network. Later there will be a lot of miners against because they already invested into HW. Bitcoin is the best example.

Scratchpad in RAM is about 8-10 times slower than scratchpad in cache. Speed on embedded CPU depends also on x64 mul/div and aes-ni. Emulation of both will be really slow. Do you plan to remove these instructions also?

In case of low-end device and light-client being two days behind it's probably more user friendly to start from transactions (check if there is some incoming coins). In case there are some incoming transactions you can display amounts as not verified yet and check PoW in the background. This way user will wait several second for downloading and transactions verification.

In case a node doesn't verifies signatures we don't have to consider it as a full node i.e. we can't rely on such node's decisions because they will accept correct PoW with wrong signature. We have to consider such nodes as light wallets. Network with majority of nodes not verifying signatures can be easily manipulated by big pools.

Let's calculate scratchpad reduction benefit for a low-end device in case of current block verification:

- 120 seconds block target time
- 10 h/s hash calculation speed

In this case one block verification takes 0.083333% of one CPU core time. Is this a showstopper for mobile device?

For current blocks relative time of PoW calculation is less than total signature verification time. The only scenario where you get significant advantage from fast PoW in block verification speed is a low-loaded chain.

I've stressed the most important part of quoted text.

I don't think that reduced scratchpad will give significant benefits to anybody because:

1. 2Mb and much bigger L3 cache becomes more and more widely used. Mobile CPU will follow soon.
2. Signature verification time is more important than PoW verification time in case of 100+ transaction per block.

Proper implementation of checkpoints will solve the full chain verification problem better than scratchpad reduction.

From the other hand small scratchpad will remove one of ASIC / GPU protection layer. It will be easier to build dedicated mining hardware: for example one can assemble a mining rig with embedded CPUs. I don't think that this is a desirable.

Can you measure relative GPU advantage over CPU with reduced scratchpad?
Original CryptoNight implementation is very good from this point of view: GPU is about 2 times faster. This is quite fair.

Hello!

What's the purpose of changing PoW?

I encountered such an effect.
As a matter of fact GUI doens't consume too much. But during full synchronization it can.

Just close it (normally, don't kill) and restart. You can do this even in the middle of synch - it will significantly reduce memory requirements.

Could you upload this wallet to Windows Store?

For Bitcoin and derived forks it's much cheaper from both computational and architectural points of view to check if this tx is mine or not. In CryptoNote wallet and daemon are separated and need additional interfaces to talk about mempool content. And key derivation also consumes CPU.

Hi!

I see a lot of work done be Bytecoin team toward CryptoNote platform improvement. Good for CryptoNote. There is a number of negative points I want to mention now:

1. Bytecoin wiki is really outdated. I hope that new interfaces will be properly documented before being released.

2. "Payment gateway designed for highload" sounds good but looks to be premature because there is no any highload even in Bitcoin traffic. Does this mean that developers are aware about forthcoming sources of highload? If "no", efforts are probably wasted. Good GUI is much more important now.

3. "Network-wide real-time transactions synchronization" ... really? How does Bytecoin now without it?

4. Simple tools and guides for merchant integration (not for highload and sophisticated scenarios but firstly for lowload and simple ones) are very important but aren't mentioned in OP. Why?

Nevertheless this is an important move from Bytecoin team.

What is the purpose of having rating?

I've started a year ago implementing torrent catalog inside Datacoin blockchain. You can see some drafts using oocook5u's datacoin-browser in testnet: http://localhost:8080/dtc-testnet/get/ad4f39667cbdccc51da2bdbe857e036d62ee6240005d554ac614cddf8f1cc20d (wait until it will reach 21340th block). You need to run dtc-http-server.pl to check this.

I think this is the time to restart this work from scratch. Here is my proposal:

In order to have a censorship protected torrent catalog we have to create database that consists of entries of the following structure:

1. magnet link
2. creative work metadata (movie title, actors, ...)
3. torrent metadata (video quality, video length, codec, ...)

Creative work metadata are widely presented in the Web and I don't think we have to copy them into the blockchain. We can use linked data instead: links to wikidata/imdb/rottentomato/... and to other data we can download and parse easily.

Below is an example of such an entry created from TPB item (13127745/Star-Wars-Episode-V-The-Empire-Strikes-Back-1980-720p-6-1ch-BRRip-AAC-x264-GeekRG-Isohunt-to) with comments. I use JSON LD format and schema.org vocabulary. JSON LD seems to be a bit fat, schema.org needs to be extended for our task but I don't see better solution now.


Technically this is enough to rebuild a very rich media database on each PC having blockchain downloaded: all details can be requested from wikidata, imdb and other external sources.

User can browse and query such a database locally by title, actors' names, video quality, audio language etc. Clicking on magnet link he will start a download with his torrent client.

This work will require a lot of manual work to establish relations between magnet links and wikidata/imdb/rottentomatos/... databases because existing TPB data are very unstructured. Volunteers doing this work can be compensated in DTC by commutiny.

Any thoughts?

198.12.12.83
162.243.125.211

Nodes mentioned above and some other are stuck a height ~476303 . I saw this bug on my side also. The easy way to solve this is to delete subdirectories "chainstate", "blocks" and "database" in "./datacoin" and start daemon again. It synchronizes to the correct height then (597460).

Don't forget to stop daemon and to backup your wallet.dat BEFORE doing this.

I can try to debug this in case node operators having this problem will share their blockchain files (chainstate, blocks and database) and debug.log.

Если бы это было что-то вроде reCAPTCHA. Мотивация у людей в сторону криптомонет велика. Это был бы повод направить усилия в общественно-полезное русло. Почти как Amazon Mechanical Turk. Для защиты вычисления лучше. А для дистрибуции монет - human PoW.

Спасибо. Это интересно.

В NameCoin имена регистрируются на время (по крайней мере в неймспейсе d/). Потом их же нужно обновлять?

Правильно ли я понимаю, что вы имеете ввиду, что по magnet ссылке торрент клиент сам найдёт .torrent файл у своих соседей?

Human proof of work - очень крутая идея. Не хватает двух вещей:
- CPU mining (ну хоть очень memory hard scrypt сгодился бы; или коллизии хешей)
- полезности человеческой работы при майнинге

Демо-версия поисковика живёт в тест-нете в транзакции ad4f39667cbdccc51da2bdbe857e036d62ee6240005d554ac614cddf8f1cc20d .

Т.е. путь dtc-testnet/get/ad4f39667cbdccc51da2bdbe857e036d62ee6240005d554ac614cddf8f1cc20d на любом DataCoin http сервере.

Он будет сканировать цепочку сверху вниз. Примеры живут в блоках 21332, 21371, 21372. Ниже 21332 ничего интересного нет. Т.е. сканер лучше остановить кнопкой, когда он пойдёт ниже, особенно, если вы будете пробовать это делать через сеть.

Интерфейс остался от браузера блокчейна (код, собственно, оттуда же).

Сегодня на хабре годный пост про семантическую разметку, в частности, про заюзанную тут schema.org :
http://habrahabr.ru/company/yandex/blog/211638/

Привет!

Я тут читал, думал, думал и, вот, придумал:

Идея:
Создать каталог торрент-файлов на базе DataCoin.

Зачем:
Чтобы каталог торрентов был всегда доступен. Даже в случае недоступности основных торрент-ресурсов. Вдруг у них там ошибка 502.

Для пользователя, который решил скачать какой-то торрент, это будет выглядеть так:

1. запустил datacoin-qt и datacoin-http сервер. Оба они свернулись в трей и больше не чирикают. Или зашёл на какой-нибудь DataCoin http сервер в сети.
2. открыл список торрентов в браузере по адресу http://localhost/dtc/get/адрес-приложения-поисковика-торрентов-которое-мы-тут-с-вами-напишем.
3. выбрал описание, нажал на ссылку, браузер скачал .torrent файл, Torrent-клиент его открыл, пошёл искать источники своими силами и начал качать. Это уже без нашей помощи.

Таким образом, для пользователя (в худшем случае) добавляется один дополнительный шаг - это запуск DataCoin софта (я очень надеюсь, что разработчики DataCoin работают над тем, чтобы это было не так мучительно, как сейчас). После этого он пользуется своим обычным браузером и своим обычным Torrent-клиентом. В самом лучшем случае datacoin-http сервера будут установлены на многих сайтах и можно будет зайти туда ничего не устанавливая. Мечтаем дальше.

Как это сделать:

Мало заслать в блокчейн .torrent файл, т.к. сами по себе .torrent файлы не содержат даже названия того ресурса, который с их помощью скачивается. Дополнительно к ним нужно добавить метаинформацию о фильме/книге/софте. Поскольку два файла в Datacoin-транзакцию помещать неудобно (нет api для одновременной отправки нескольких файлов), то .torrent и метаиформацию можно разместить в двух последовательных транзакциях.

В качестве формата для метаинформации (чтобы не изобретать велосипед) можно использовать словарь schema.org (который для вебмастеров от Гугла и Яндекса) в формате json-ld. В schema.org есть более чем избыточный набор "тегов" для описания фильмов и т.д. В этом формате метаинформация может выглядеть, например, вот так:

{
  "@context": { "@vocab": "http://schema.org/" },
  "@type": "Movie",
  "name": [{ "@value": "Star Wars 115 (Creative Commons Edition)", "@language": "en" }],
  "sameAs": "http://en.wikipedia.org/wiki/Star_Wars_115",
  "datePublished": "2015-04-01",
  "genre": "drama / comedy / horror",
  "description": "Тайная группа фанатов звёздных войн выложила, наконец, очередной эпизод сериала.",
  "director": [{ "@type": "Person", "givenName": "Иван", "familyName": "Паравозов" }],
  "publishingPrinciples": "http://creativecommons.org/licenses/by-sa/4.18/",
  "video": [{
    "@type": "VideoObject",
    "name": [{ "@value": "Star Wars 115", "@language": "en" }],
    "contentSize": "4.33 GiB",
    "uploadDate": "2015-04-02",
    "contentUrl": "c31f7f8bdcecbb218935da3eac937c77e48a6e4d37c1d2624c2f54acea9de62b"
  }]
}

Таким образом, публикация торрента в DataCoin будет выглядеть следующим образом:

1. Положить в DataCoin myfilm.torrent и записать id траназкции
2. Составить myfilm.jsonld, вписать туда
  - описание фильма
  - id транзакции с .torrent файлом
3. Положить в DataCoin myfilm.jsonld

Приложение, ищущее торренты в блокчейне, ищет среди всех файлов те, у которых проставлен Content-Type:application/json+ld и отображать их список или как-то ещё искать по ним. Если не будет хватать данных в json+ld описании (например, ищем по актёру, а имена актёров не перечислены), то это же приложение может сходить в DBpedia, imdb или в Википедию по указанным ссылкам и догрузить недостающее. Это, собственно, к тому, что поле "sameAs" тут не для красоты, а описание можно делать довольно коротким, т.к. вся необходимая инфа для поиска в сети уже есть и вряд ли куда-то денется. Чего нельзя сказать о торрент сайтах, которые могут стать недоступны вне зависимости от легальности раздаваемого там. Я к тому, что и вполне законопослушный ресурс может пасть смертью храбрых, например, под DDoSом. А для пользователя важна надёжность.

Само по себе приложение я предлагаю сделать по аналогии с block explorer ( http://ec2-54-201-144-165.us-west-2.compute.amazonaws.com/dtc/get/40a3eb9624528008a87d9119dbed4041d45c9f6483ecd52a7b24f9c8b4fdf548 ), который предложил oocook5u (разработчик Datacoin). Это чисто HTML/JavaScript страница, которая читает цепочку блоков через HTTP шлюз к стандартному JSON-RPC API. Ну, короче, эту часть в его постах я, вроде понял, и, при необходимости, я могу объяснить подробно любому веб-программисту.

Для того, чтобы мотивировать пользователей заливать туда торренты, надо будет сделать возможность послать монетку на тот адрес, с которого торрент-файл был залит или на какой-нибудь специальный адрес, связанный с конкретным торрентом (указывать в .jsonld?). Для этого, правда, нужно, чтобы разблокировали комиссию. Для такой формы оплаты она, наверное, высоковата. Суммы на этих адресах можно будет далее учитывать при ранжировании списка (или не стоит?).

Аналогичным образом, можно включать адрес для donation правообладателю в .jsonld и подписывать этот адрес всем известным закрытым ключом этого правообладателя. Т.е. вопрос легальности раздачи касается только двоих: отправляющего и скачивающего. Наша задача - предоставить им возможность обменяться информацией так, чтобы они друг друга однозначно поняли. Подпись адреса для donation правообладателем - это способ сообщить скачивающему о легальности раздачи. Или, по крайней мере, о точке зрения правообладателя на вопрос легальности (может же и врать).

Короче, если вам показалось, что я тут пишу про пиратство, то это не так. Я тут скорее про возможность пообщаться без посредников. Я верю, что, однажды, случится день, когда мы все станем достаточно взрослыми, чтобы такая форма взаимодействия была для нас оптимальной. Теперь возвращаемся к техническим вопросам.

Что именно нужно сделать:

- приложение-поисковик торрентов (то, чем будут пользоваться 99% причастных, которые ничего не публикуют, а только скачивают)
  Я сейчас переделывают тот block explorer. Из этого получится как минимум прототип с основными функциями. Но интерфейс у него уродский. Поэтому я ищу дизайнера, который нарисовал бы классный интерфейс и программиста, который бы его закодил.

- приложение-загрузчик торрента и его описания в DataCoin
  Это можно сделать на основе кода из репозитория DataCoin (который на Perl). Или в виде отдельного Qt приложения, которое общается с DataCoin-демоном по JSON-RPC. Для Qt приложения нужен Qt программист.

Программа-максимум:

- краудфандинговый сайт-загрузчик торрентов
  Поскольку отправка файлов в блокчейн приводит к трате монет, а загружающий, в общем случае, не обязан тратить монеты, то возможен ещё и такой сценарий:
  - Пользователь загружает на сайт .torrent и .jsonld
  - На сайте создаётся отдельный DataCoin адрес для пожертвований за то, чтобы включить этот торрент-файл в блокчейн. Известна необходимая сумма комиссии за включение файла в цепочку. Когда пожертвований набирается достаточное количество, то сайт автоматически отсылает оба файла в блокчейн.
  Это чуть сложнее, чем всё предыдущее. Кто умеет и хочет взяться за это?

Ну, и вообще, что думаете?
Может быть кто-то уже делает что-то подобное?

Подробности про идеи DataCoin от его создателя (англ.):
[1] Основная ветка https://bitcointalk.org/index.php?topic=325735.0
[2] Про block explorer и приложения в blockchain https://bitcointalk.org/index.php?topic=405992.0

Very nice picture!
I think that the best place for this [ANN] is in the "Alternative" subforum. I've announced this in Russian part of forum.

Для этого поста ( https://bitcointalk.org/index.php?topic=448601.0 ) здесь самое правильное место. На сайте http://mapofcoins.com/ нарисовали генеалогическое древо криптовалют (кто кого форкал). Можно посмотреть, как это выглядело в предыдущие месяцы, когда валют было меньше.

Глядя на эту картинку, кажется очевидным, что функциональность bitcoin (типы транзакций и прочее) всех вполне устраивает. Улучшения касаются трёх тем:

1. майнинг. Основные нововведения: Scrypt и его разновидности (Tenebrix/Litecoin, Yacoin, ...), PoS (PPCoin), цепочки простых чисел (Primecoin), коллизии хешей (ProtoShares), полезные вычисления (GridCoin, CureCoin).

2. навешивание на blockchain дополнительной функциональности (NameCoin, DataCoin).

3. продвижение (DogeCoin, MMMCoin, ...)

Остальные нововведения - это изменение частоты блоков и награды за них - это не так интересно